From erik.joelsson at oracle.com Wed Apr 1 07:56:35 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 01 Apr 2015 09:56:35 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551ACDBD.6000703@oracle.com> References: <551ACDBD.6000703@oracle.com> Message-ID: <551BA4B3.7010105@oracle.com> Hello, (Adding build-dev since this touches makefiles and jigsaw-dev since this touches modules.xml) In general, the build changes look pretty good. I much appreciate moving the OS specific source into OS specific source dirs. A few notes however. Though I realize you followed existing patterns, we have some more current best practices that I would like to incorporate in new code. jdk/make/lib/Lib-jdk.management.gmk: The variables BUILD_LIBJDKMANAGEMENT_SRC and BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While it works, it makes them unnecessarily long and it risks conflicting with internal variables created in the SetupNativeCompilation call. BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. The EXCLUDE_FILES parameter too. LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special construct for libmanagement used for a while until cmm was split into a separate module. Just inline the mapfile line into the macro call. jdk/make/lib/Lib-java.management.gmk: BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well. LIBMANAGEMENT_MAPFILE should be inlined here as well. While you are at it, might as well fix the BUILD_ prefix on the SRC and CFLAGS variables here too if you don't mind. Is the need for low optimization when debug symbols are active still valid for both libmanagement and libmanagement_ext? /Erik On 2015-03-31 18:39, shanliang wrote: > Please review this fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ > > Some code within the module java.management is separated and moved to > the new module jdk.management, the new module takes the implementation > code for Oracle Corporation's platform extension to the implementation > of the java.lang.management API and also the management interface for > some other components for the platform. > > Thanks, > Shanliang > From jaroslav.bachorik at oracle.com Wed Apr 1 08:56:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 01 Apr 2015 10:56:29 +0200 Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.Error: 'MaxHeapSize' flag is not available or immutable" Message-ID: <551BB2BD.6030306@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8076344 Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00 Originally, the test used some well known flags to assert the correct functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so quickly :) The solution is to pick whichever mutable/immutable flag of a certain type and carry on the test using this flag. This way the test will always use only the available flags. Thanks, -JB- From staffan.larsen at oracle.com Wed Apr 1 09:04:11 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Apr 2015 11:04:11 +0200 Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.Error: 'MaxHeapSize' flag is not available or immutable" In-Reply-To: <551BB2BD.6030306@oracle.com> References: <551BB2BD.6030306@oracle.com> Message-ID: Looks good! nit: L133: ?existeng? -> ?existing" Thanks, /Staffan > On 1 apr 2015, at 10:56, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8076344 > Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00 > > Originally, the test used some well known flags to assert the correct functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so quickly :) > > The solution is to pick whichever mutable/immutable flag of a certain type and carry on the test using this flag. This way the test will always use only the available flags. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Apr 1 12:07:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 01 Apr 2015 14:07:30 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551ACDBD.6000703@oracle.com> References: <551ACDBD.6000703@oracle.com> Message-ID: <551BDF82.4010908@oracle.com> Hi Shanliang, Looks good! A lot of work here ... Just a nit - * jdk/src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java - superfluous import @L28 (and the copyright year change) I suppose all reg-tests and related JCK tests are still passing. -JB- On 31.3.2015 18:39, shanliang wrote: > Please review this fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ > > Some code within the module java.management is separated and moved to > the new module jdk.management, the new module takes the implementation > code for Oracle Corporation's platform extension to the implementation > of the java.lang.management API and also the management interface for > some other components for the platform. > > Thanks, > Shanliang > From staffan.larsen at oracle.com Wed Apr 1 14:02:15 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Apr 2015 16:02:15 +0200 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> <54E1E6FE.8030706@redhat.com> <54E759C5.9040301@redhat.com> Message-ID: Thanks for the feedback. I still think that the cost and drawbacks of the hprof agent outweighs the benefits and will move ahead with the JEP. It can be noted that since the hprof agent uses the standardized JVMTI interface, it should be perfectly possible to use the library shipped with a previous version of the JDK. Still a bit messy, but workable. Thanks, /Staffan From shanliang.jiang at oracle.com Wed Apr 1 14:24:38 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 01 Apr 2015 16:24:38 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551BDF82.4010908@oracle.com> References: <551ACDBD.6000703@oracle.com> <551BDF82.4010908@oracle.com> Message-ID: <551BFFA6.3040504@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > > Looks good! A lot of work here ... > > Just a nit - > > * > jdk/src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java > > - superfluous import @L28 (and the copyright year change) Yes the import of L28 is unnecessary. The copyright year was changed because the package was changed. > > I suppose all reg-tests and related JCK tests are still passing. I passed svc/core/hotspot unit tests with jprt, and JMX JCK tests. Thanks for the review. Shanliang > > -JB- > > On 31.3.2015 18:39, shanliang wrote: >> Please review this fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ >> >> Some code within the module java.management is separated and moved to >> the new module jdk.management, the new module takes the implementation >> code for Oracle Corporation's platform extension to the implementation >> of the java.lang.management API and also the management interface for >> some other components for the platform. >> >> Thanks, >> Shanliang >> > From daniel.fuchs at oracle.com Wed Apr 1 16:58:20 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 01 Apr 2015 18:58:20 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551ACDBD.6000703@oracle.com> References: <551ACDBD.6000703@oracle.com> Message-ID: <551C23AC.9000209@oracle.com> Hi Shanliang, Impressive work! I know how long it took you and how much effort went into this! This does look good. One minor remark is that it might have been good to have a simple mechanical rule to transform the name of the MBean concrete implementation from the java.management module to the jdk.management module, since these concrete class names may need to be referred to in an application policy file. For instance - if we could say: << Implementation class names of MBeans which do not have a com.sun.management extension are unchanged (that is still true - I think). Implementation class names of MBeans which do have a com.sun.management extension are changed so that their package name moves from sun.management. to com.sun.management.internal. >> At this point however there doesn't seem to be such a simple pattern, apart from the fact that the implementation have moved to com.sun.management.internal. For instance we have: before: sun.management.OperatingSystemImpl after: java.management: sun.management.BaseOperatingSystemImpl jdk.management: com.sun.management.internal.OperatingSystemImpl before: sun.management.GarbageCollectorImpl after: java.management: sun.management.GarbageCollectorImpl jdk.management: com.sun.management.internal.GarbageCollectorExtImpl before: sun.management.ThreadImpl after: java.management: sun.management.ThreadImpl jdk.management: com.sun.management.internal.HotSpotThreadImpl But this is minor compared to the rest of the work, and maybe that could be left over for later - if that's ever needed. best regards, -- daniel On 31/03/15 18:39, shanliang wrote: > Please review this fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ > > Some code within the module java.management is separated and moved to > the new module jdk.management, the new module takes the implementation > code for Oracle Corporation's platform extension to the implementation > of the java.lang.management API and also the management interface for > some other components for the platform. > > Thanks, > Shanliang > From shanliang.jiang at oracle.com Wed Apr 1 18:03:04 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 01 Apr 2015 20:03:04 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551BA4B3.7010105@oracle.com> References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com> Message-ID: <551C32D8.3020100@oracle.com> Erik Joelsson wrote: > Hello, > > (Adding build-dev since this touches makefiles and jigsaw-dev since > this touches modules.xml) > > In general, the build changes look pretty good. I much appreciate > moving the OS specific source into OS specific source dirs. A few > notes however. Though I realize you followed existing patterns, we > have some more current best practices that I would like to incorporate > in new code. > > jdk/make/lib/Lib-jdk.management.gmk: > > The variables BUILD_LIBJDKMANAGEMENT_SRC and > BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While > it works, it makes them unnecessarily long and it risks conflicting > with internal variables created in the SetupNativeCompilation call. Done. > > BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. > The EXCLUDE_FILES parameter too. Done. > > LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special > construct for libmanagement used for a while until cmm was split into > a separate module. Just inline the mapfile line into the macro call. Done. > > > jdk/make/lib/Lib-java.management.gmk: > > BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well. Removed. > > LIBMANAGEMENT_MAPFILE should be inlined here as well. Done. > > While you are at it, might as well fix the BUILD_ prefix on the SRC > and CFLAGS variables here too if you don't mind. Done. > > > Is the need for low optimization when debug symbols are active still > valid for both libmanagement and libmanagement_ext? Sorry I do not know, I did not touch that flag stting in libmanagement, and I copied it for libmanagement_ext. Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/ Thanks for the review. Shanliang > > /Erik > > On 2015-03-31 18:39, shanliang wrote: >> Please review this fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ >> >> Some code within the module java.management is separated and moved to >> the new module jdk.management, the new module takes the >> implementation code for Oracle Corporation's platform extension to >> the implementation of the java.lang.management API and also the >> management interface for some other components for the platform. >> >> Thanks, >> Shanliang >> > From mandy.chung at oracle.com Wed Apr 1 21:41:54 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 Apr 2015 14:41:54 -0700 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551ACDBD.6000703@oracle.com> References: <551ACDBD.6000703@oracle.com> Message-ID: <551C6622.1020609@oracle.com> On 3/31/2015 9:39 AM, shanliang wrote: > Please review this fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ Thank you for doing this big change to separate com.sun.management API from java.management module. Looking really good. Also thanks for fixing the tests to eliminate the unnecessary use of JDK internal APIs. modules.xml change looks good to me. sun/management/ThreadImpl.java 35 /** 36 * Implementation class for the thread subsystem. 37 * Standard and committed hotspot-specific metrics if any. 38 * 39 * ManagementFactory.getThreadMXBean() returns an instance 40 * of this class. 41 */ 42 // the implementation for com.sun.management.ThreadMXBean can 43 // be moved to jdk.management in the future. What about: Implementation for java.lang.management.ThreadMXBean as well as providing the supporting method for com.sun.management.ThreadMXBean. The supporting method for com.sun.management.ThreadMXBean can be moved to jdk.management in the future. CheckSomeMXBeanImplPackage.java Thanks for adding this test. Iterating jrt file system to find jdk.management module is one way. Another simpler alternative is to call: Class.forName("com.sun.management.GarbageCollectorMXBean"); and catch CNFE to determine if it's present or not. You should also call ManagementFactory.getPlatformMXBeans on com.sun.management.GarbageCollectorMXBean if present. VMOptionOpenDataTest.java copyright header year is wrong. PlatformMBeanProviderConstructorCheck.java The test needs to restore the original policy and security manager before the test exits in case this case runs in agent vm mode. The static permName and accepted variables are more appropriate in MyPolicy class. Perhaps rename "accepted" to an instance "denied" or "allowed" variable of MyPolicy class to reflect what it intends to mean. I'm okay if you make the change before the push. No need for a new webrev. Mandy From david.holmes at oracle.com Wed Apr 1 22:26:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 08:26:48 +1000 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <55186449.4050606@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> <55186449.4050606@oracle.com> Message-ID: <551C70A8.6080304@oracle.com> On 30/03/2015 6:44 AM, David Holmes wrote: > On 27/03/2015 5:36 PM, cheleswer sahu wrote: >> Hi, >> Please review the code changes for >> https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 >> with fix successfully. As I do not have account for OpenJDK, David Buck >> will push >> the fix into jdk9/hs-rt/. >> >> Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ > > Is it possible to include information about where the class was loaded > from in the message that precedes the exit: > > 121 tty->print_cr("Invalid layout of %s at %s", > ik->external_name(), name_symbol->as_C_string()); > > The main cause of this problem is android.jar on the bootclasspath. It > would be good to make that explicit as well. Otherwise we will still get > bug reports because noone will know what this error means. I had a good look and it seems the information is not preserved once the class has been loaded. Can I suggest this simple addition instead: vm_exit_during_initialization("Invalid layout of preloaded class: use -XX:+TraceClassLoading to see the origin of the problem class"); Thanks, David > Thanks, > David > > >> Regards, >> Cheleswer >> >> >> >> From erik.joelsson at oracle.com Thu Apr 2 07:43:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 02 Apr 2015 09:43:34 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551C32D8.3020100@oracle.com> References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com> <551C32D8.3020100@oracle.com> Message-ID: <551CF326.5010402@oracle.com> Looks good, thanks! /Erik On 2015-04-01 20:03, shanliang wrote: > Erik Joelsson wrote: >> Hello, >> >> (Adding build-dev since this touches makefiles and jigsaw-dev since >> this touches modules.xml) >> >> In general, the build changes look pretty good. I much appreciate >> moving the OS specific source into OS specific source dirs. A few >> notes however. Though I realize you followed existing patterns, we >> have some more current best practices that I would like to >> incorporate in new code. >> >> jdk/make/lib/Lib-jdk.management.gmk: >> >> The variables BUILD_LIBJDKMANAGEMENT_SRC and >> BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While >> it works, it makes them unnecessarily long and it risks conflicting >> with internal variables created in the SetupNativeCompilation call. > Done. >> >> BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. >> The EXCLUDE_FILES parameter too. > Done. >> >> LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special >> construct for libmanagement used for a while until cmm was split into >> a separate module. Just inline the mapfile line into the macro call. > Done. >> >> >> jdk/make/lib/Lib-java.management.gmk: >> >> BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well. > Removed. >> >> LIBMANAGEMENT_MAPFILE should be inlined here as well. > Done. >> >> While you are at it, might as well fix the BUILD_ prefix on the SRC >> and CFLAGS variables here too if you don't mind. > Done. >> >> >> Is the need for low optimization when debug symbols are active still >> valid for both libmanagement and libmanagement_ext? > Sorry I do not know, I did not touch that flag stting in > libmanagement, and I copied it for libmanagement_ext. > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/ > > Thanks for the review. > Shanliang > >> >> /Erik >> >> On 2015-03-31 18:39, shanliang wrote: >>> Please review this fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 >>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ >>> >>> Some code within the module java.management is separated and moved >>> to the new module jdk.management, the new module takes the >>> implementation code for Oracle Corporation's platform extension to >>> the implementation of the java.lang.management API and also the >>> management interface for some other components for the platform. >>> >>> Thanks, >>> Shanliang >>> >> > From dmitry.samersoff at oracle.com Thu Apr 2 11:27:31 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 02 Apr 2015 14:27:31 +0300 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect Message-ID: <551D27A3.1040606@oracle.com> Everybody, Please review a small fix. The fix goes to 9 and 8u at the same time. http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Thu Apr 2 11:45:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Apr 2015 21:45:25 +1000 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D27A3.1040606@oracle.com> References: <551D27A3.1040606@oracle.com> Message-ID: <551D2BD5.6010206@oracle.com> Hi Dmitry, On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: > Everybody, > > Please review a small fix. > > The fix goes to 9 and 8u at the same time. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ Not sure I understand the bug synopsis in relation to the fix. Sounds like FindBugs complained about using a protected static field that was set directly via a subclass. Not sure why. So now we have a private field that can be set by anyone via a public method. Maybe the setInstance method should be protected not public? But do we really care? Either ways seems fine to me if it silences FindBugs. David > -Dmitry > From dmitry.samersoff at oracle.com Thu Apr 2 12:05:54 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 02 Apr 2015 15:05:54 +0300 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D2BD5.6010206@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> Message-ID: <551D30A2.4070003@oracle.com> David, On 2015-04-02 14:45, David Holmes wrote: > Hi Dmitry, > > On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review a small fix. >> >> The fix goes to 9 and 8u at the same time. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ > > Not sure I understand the bug synopsis in relation to the fix. Sounds > like FindBugs complained about using a protected static field that was > set directly via a subclass. Not sure why. So now we have a private > field that can be set by anyone via a public method. Maybe the > setInstance method should be protected not public? Agree - I'll update the fix. > But do we really care? Either ways seems fine to me if it silences > FindBugs. Yes, this is the goal. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yekaterina.kantserova at oracle.com Thu Apr 2 12:16:43 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 02 Apr 2015 14:16:43 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect Message-ID: <551D332B.3060002@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8027668 webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ The tests can still contain a race. There is a possibility the jstad is not really started though there is a pid for the process. The suggestion is to let jstatd notify it's started and for the test wait until this notification. Thanks, Katja From dmitry.samersoff at oracle.com Thu Apr 2 12:35:33 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 02 Apr 2015 15:35:33 +0300 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D30A2.4070003@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> Message-ID: <551D3795.1050002@oracle.com> Fix updated. On 2015-04-02 15:05, Dmitry Samersoff wrote: > David, > > > On 2015-04-02 14:45, David Holmes wrote: >> Hi Dmitry, >> >> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review a small fix. >>> >>> The fix goes to 9 and 8u at the same time. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ >> >> Not sure I understand the bug synopsis in relation to the fix. Sounds >> like FindBugs complained about using a protected static field that was >> set directly via a subclass. Not sure why. So now we have a private >> field that can be set by anyone via a public method. Maybe the >> setInstance method should be protected not public? > > Agree - I'll update the fix. > >> But do we really care? Either ways seems fine to me if it silences >> FindBugs. > > Yes, this is the goal. > > -Dmitry > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Apr 2 12:44:36 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 02 Apr 2015 14:44:36 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <551D332B.3060002@oracle.com> References: <551D332B.3060002@oracle.com> Message-ID: <551D39B4.70506@oracle.com> Hi Katja, On 2.4.2015 14:16, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8027668 > webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout. Please, update the copyright years. -JB- > > The tests can still contain a race. There is a possibility the jstad is > not really started though there is a pid for the process. The suggestion > is to let jstatd notify it's started and for the test wait until this > notification. > > Thanks, > Katja From jaroslav.bachorik at oracle.com Thu Apr 2 12:45:50 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 02 Apr 2015 14:45:50 +0200 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D3795.1050002@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com> Message-ID: <551D39FE.20402@oracle.com> On 2.4.2015 14:35, Dmitry Samersoff wrote: > Fix updated. I like this better. Still rather convoluted but it seems to be as good as we can get without a bigger rewrite. I'm ok with this change. Cheers, -JB- > > On 2015-04-02 15:05, Dmitry Samersoff wrote: >> David, >> >> >> On 2015-04-02 14:45, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review a small fix. >>>> >>>> The fix goes to 9 and 8u at the same time. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ >>> >>> Not sure I understand the bug synopsis in relation to the fix. Sounds >>> like FindBugs complained about using a protected static field that was >>> set directly via a subclass. Not sure why. So now we have a private >>> field that can be set by anyone via a public method. Maybe the >>> setInstance method should be protected not public? >> >> Agree - I'll update the fix. >> >>> But do we really care? Either ways seems fine to me if it silences >>> FindBugs. >> >> Yes, this is the goal. >> >> -Dmitry >> >> > > From dmitry.samersoff at oracle.com Thu Apr 2 12:51:57 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 02 Apr 2015 15:51:57 +0300 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D39FE.20402@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com> <551D39FE.20402@oracle.com> Message-ID: <551D3B6D.2040300@oracle.com> Jaroslav, Thank you! -Dmitry On 2015-04-02 15:45, Jaroslav Bachorik wrote: > On 2.4.2015 14:35, Dmitry Samersoff wrote: >> Fix updated. > > I like this better. Still rather convoluted but it seems to be as good > as we can get without a bigger rewrite. > > I'm ok with this change. > > Cheers, > > -JB- > >> >> On 2015-04-02 15:05, Dmitry Samersoff wrote: >>> David, >>> >>> >>> On 2015-04-02 14:45, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review a small fix. >>>>> >>>>> The fix goes to 9 and 8u at the same time. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ >>>> >>>> Not sure I understand the bug synopsis in relation to the fix. Sounds >>>> like FindBugs complained about using a protected static field that was >>>> set directly via a subclass. Not sure why. So now we have a private >>>> field that can be set by anyone via a public method. Maybe the >>>> setInstance method should be protected not public? >>> >>> Agree - I'll update the fix. >>> >>>> But do we really care? Either ways seems fine to me if it silences >>>> FindBugs. >>> >>> Yes, this is the goal. >>> >>> -Dmitry >>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Apr 2 12:54:35 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 02 Apr 2015 15:54:35 +0300 Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect Message-ID: <551D3C0B.3080803@oracle.com> Everybody, Please review a small fix: The fix goes to 9 and 8u at the same time. http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yekaterina.kantserova at oracle.com Thu Apr 2 12:56:13 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 02 Apr 2015 14:56:13 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <551D39B4.70506@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> Message-ID: <551D3C6D.2060000@oracle.com> Jaroslav, thanks, will do! // Katja On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: > Hi Katja, > > On 2.4.2015 14:16, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ > > In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would > suggest adding System.out.flush() after printing "jstatd is started on > ..." to make sure the output is actually committed to stdout. > > Please, update the copyright years. > > -JB- > >> >> The tests can still contain a race. There is a possibility the jstad is >> not really started though there is a pid for the process. The suggestion >> is to let jstatd notify it's started and for the test wait until this >> notification. >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Thu Apr 2 12:56:45 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 02 Apr 2015 14:56:45 +0200 Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551D3C0B.3080803@oracle.com> References: <551D3C0B.3080803@oracle.com> Message-ID: <551D3C8D.8000008@oracle.com> Hi, Looks good. Just update the copyright year. -JB- On 2.4.2015 14:54, Dmitry Samersoff wrote: > Everybody, > > Please review a small fix: > > The fix goes to 9 and 8u at the same time. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ > > -Dmitry > From staffan.larsen at oracle.com Thu Apr 2 13:04:20 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 2 Apr 2015 15:04:20 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <551D3C6D.2060000@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> <551D3C6D.2060000@oracle.com> Message-ID: <5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com> What does the name.toString() look like? Should the message be ?jstatd listening on ??? > On 2 apr 2015, at 14:56, Yekaterina Kantserova wrote: > > Jaroslav, > > thanks, will do! > > // Katja > > > > On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> On 2.4.2015 14:16, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ >> >> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout. >> >> Please, update the copyright years. >> >> -JB- >> >>> >>> The tests can still contain a race. There is a possibility the jstad is >>> not really started though there is a pid for the process. The suggestion >>> is to let jstatd notify it's started and for the test wait until this >>> notification. >>> >>> Thanks, >>> Katja >> > From yekaterina.kantserova at oracle.com Thu Apr 2 13:29:22 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 02 Apr 2015 15:29:22 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> <551D3C6D.2060000@oracle.com> <5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com> Message-ID: <551D4432.3000700@oracle.com> name is a combination of: rmi name = Name to which the remote RMI object is bound in the RMI registry port = Port number where the RMI registry is expected to be found "jstatd is bound to ..."? // Katja > What does the name.toString() look like? Should the message be ?jstatd listening on ??? > >> On 2 apr 2015, at 14:56, Yekaterina Kantserova wrote: >> >> Jaroslav, >> >> thanks, will do! >> >> // Katja >> >> >> >> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: >>> Hi Katja, >>> >>> On 2.4.2015 14:16, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ >>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout. >>> >>> Please, update the copyright years. >>> >>> -JB- >>> >>>> The tests can still contain a race. There is a possibility the jstad is >>>> not really started though there is a pid for the process. The suggestion >>>> is to let jstatd notify it's started and for the test wait until this >>>> notification. >>>> >>>> Thanks, >>>> Katja From cheleswer.sahu at oracle.com Thu Apr 2 15:31:24 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Thu, 02 Apr 2015 21:01:24 +0530 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <55186449.4050606@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> <55186449.4050606@oracle.com> Message-ID: <551D60CC.10909@oracle.com> Hi, Please review the new code changes. I have incorporated the suggestion received from 'David Holmes' in code and built successfully. As I do not have account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.02/ Regards, Cheleswer On 3/30/2015 2:14 AM, David Holmes wrote: > On 27/03/2015 5:36 PM, cheleswer sahu wrote: >> Hi, >> Please review the code changes for >> https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 >> with fix successfully. As I do not have account for OpenJDK, David Buck >> will push >> the fix into jdk9/hs-rt/. >> >> Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ > > Is it possible to include information about where the class was loaded > from in the message that precedes the exit: > > 121 tty->print_cr("Invalid layout of %s at %s", > ik->external_name(), name_symbol->as_C_string()); > > The main cause of this problem is android.jar on the bootclasspath. It > would be good to make that explicit as well. Otherwise we will still > get bug reports because noone will know what this error means. > > Thanks, > David > > >> Regards, >> Cheleswer >> >> >> >> From serguei.spitsyn at oracle.com Thu Apr 2 19:44:26 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 02 Apr 2015 12:44:26 -0700 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D3795.1050002@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com> Message-ID: <551D9C1A.5030008@oracle.com> Looks good. Thanks, Serguei On 4/2/15 5:35 AM, Dmitry Samersoff wrote: > Fix updated. > > On 2015-04-02 15:05, Dmitry Samersoff wrote: >> David, >> >> >> On 2015-04-02 14:45, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review a small fix. >>>> >>>> The fix goes to 9 and 8u at the same time. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ >>> Not sure I understand the bug synopsis in relation to the fix. Sounds >>> like FindBugs complained about using a protected static field that was >>> set directly via a subclass. Not sure why. So now we have a private >>> field that can be set by anyone via a public method. Maybe the >>> setInstance method should be protected not public? >> Agree - I'll update the fix. >> >>> But do we really care? Either ways seems fine to me if it silences >>> FindBugs. >> Yes, this is the goal. >> >> -Dmitry >> >> > From serguei.spitsyn at oracle.com Thu Apr 2 19:46:58 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 02 Apr 2015 12:46:58 -0700 Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551D3C0B.3080803@oracle.com> References: <551D3C0B.3080803@oracle.com> Message-ID: <551D9CB2.3070405@oracle.com> Looks good. Thanks, Serguei On 4/2/15 5:54 AM, Dmitry Samersoff wrote: > Everybody, > > Please review a small fix: > > The fix goes to 9 and 8u at the same time. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ > > -Dmitry > From shanliang.jiang at oracle.com Thu Apr 2 19:58:14 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Thu, 02 Apr 2015 21:58:14 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551C6622.1020609@oracle.com> References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com> Message-ID: <551D9F56.4050201@oracle.com> Hi, I have to ask the review again because I need to modify: langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java The issue was found when langtools tests were added into my test list. The new version is: http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/ which integrated also the Mandy's comments in the following mail. Thanks, Shanliang Mandy Chung wrote: > On 3/31/2015 9:39 AM, shanliang wrote: >> Please review this fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/ > > Thank you for doing this big change to separate com.sun.management > API from java.management module. Looking really good. > > Also thanks for fixing the tests to eliminate the unnecessary use of > JDK internal APIs. > > modules.xml change looks good to me. > > sun/management/ThreadImpl.java > 35 /** > 36 * Implementation class for the thread subsystem. > 37 * Standard and committed hotspot-specific metrics if any. > 38 * > 39 * ManagementFactory.getThreadMXBean() returns an instance > 40 * of this class. > 41 */ > 42 // the implementation for com.sun.management.ThreadMXBean can > 43 // be moved to jdk.management in the future. > > What about: > Implementation for java.lang.management.ThreadMXBean as well as > providing the supporting method for com.sun.management.ThreadMXBean. > The supporting method for com.sun.management.ThreadMXBean can > be moved to jdk.management in the future. > > CheckSomeMXBeanImplPackage.java > Thanks for adding this test. > > Iterating jrt file system to find jdk.management module is one way. > Another simpler alternative is to call: > Class.forName("com.sun.management.GarbageCollectorMXBean"); > and catch CNFE to determine if it's present or not. > > You should also call ManagementFactory.getPlatformMXBeans on > com.sun.management.GarbageCollectorMXBean if present. > > VMOptionOpenDataTest.java > copyright header year is wrong. > > PlatformMBeanProviderConstructorCheck.java > The test needs to restore the original policy and security manager > before the test exits in case this case runs in agent vm mode. > The static permName and accepted variables are more appropriate > in MyPolicy class. Perhaps rename "accepted" to an instance > "denied" or "allowed" variable of MyPolicy class to reflect > what it intends to mean. > > I'm okay if you make the change before the push. No need for a new > webrev. > > Mandy > From mandy.chung at oracle.com Thu Apr 2 20:09:08 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 02 Apr 2015 13:09:08 -0700 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551D9F56.4050201@oracle.com> References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com> <551D9F56.4050201@oracle.com> Message-ID: <551DA1E4.6070709@oracle.com> On 4/2/15 12:58 PM, Shanliang Jiang wrote: > Hi, > > I have to ask the review again because I need to modify: > langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java > > The issue was found when langtools tests were added into my test list. > > The new version is: > http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/ > Thanks for catching the jdeps change. Profile.java change looks okay and this list is temporary. jdeps will be updated to determine the exported APIs at runtime when the module system is moving along. > which integrated also the Mandy's comments in the following mail. > CheckSomeMXBeanImplPackage.java line 45-50 & 58-60: should be called unconditionally since they should pass if java.management is present. Okay to push once the test is updated. Mandy From serguei.spitsyn at oracle.com Fri Apr 3 00:03:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 02 Apr 2015 17:03:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. Message-ID: <551DD8BB.5040001@oracle.com> Please, review the jdk 8u60 backport for: https://bugs.openjdk.java.net/browse/JDK-8067662 8u60 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 8u60 webrev for unit test update (the fix applies cleanly): http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 9 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 9 webrev for unit test update: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 Summary: The 9 fix can not be applied cleanly so that I have to rework the fix a little bit. An NPE is trown in a thread dumping via JMX when doing CPU profiling in NetBeans Profiler and VisualVM. The issue is that the methods and related klass versions are not kept alive if a class redefinition takes place between catching a Throwable and taking a thread dump. It can result in loosing an obsolete method, and so, the reconstruction of method name becomes impossible. In such a case, the null reference is returned instead of a valid method name. The solution is to use current klass version and method orig_idnum instead of ordinary method idnum to find required method pointer. In the worst case when the related klass version is gone (was not included to or was removed from the previous_versions linked list), a saved method name CP index of the latest klass version can be used to restore the method name. The footprint extra overhead for this approach is u2 per stack frame. Testing in progress: In progress: nsk redefine classes tests, JTREG java/lang/instrument Thanks, Serguei From david.holmes at oracle.com Fri Apr 3 01:00:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Apr 2015 11:00:06 +1000 Subject: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect In-Reply-To: <551D3795.1050002@oracle.com> References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com> Message-ID: <551DE616.4060609@oracle.com> Looks good. Thanks, David On 2/04/2015 10:35 PM, Dmitry Samersoff wrote: > Fix updated. > > On 2015-04-02 15:05, Dmitry Samersoff wrote: >> David, >> >> >> On 2015-04-02 14:45, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review a small fix. >>>> >>>> The fix goes to 9 and 8u at the same time. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ >>> >>> Not sure I understand the bug synopsis in relation to the fix. Sounds >>> like FindBugs complained about using a protected static field that was >>> set directly via a subclass. Not sure why. So now we have a private >>> field that can be set by anyone via a public method. Maybe the >>> setInstance method should be protected not public? >> >> Agree - I'll update the fix. >> >>> But do we really care? Either ways seems fine to me if it silences >>> FindBugs. >> >> Yes, this is the goal. >> >> -Dmitry >> >> > > From shanliang.jiang at oracle.com Fri Apr 3 07:30:52 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Fri, 03 Apr 2015 09:30:52 +0200 Subject: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management In-Reply-To: <551DA1E4.6070709@oracle.com> References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com> <551D9F56.4050201@oracle.com> <551DA1E4.6070709@oracle.com> Message-ID: <551E41AC.6000407@oracle.com> Mandy Chung wrote: > CheckSomeMXBeanImplPackage.java > line 45-50 & 58-60: should be called unconditionally since they > should pass if java.management is present. The method "check" checks that an MBean implementation must be from "com.sun.management.internal", so even we look for an MXBean with its standard MXBean class (java.lang.management.*), do "check" still needs jdk.management module to be present. We need more unit tests for the case when jdk.management is absent. Thanks, Shanliang From jaroslav.bachorik at oracle.com Fri Apr 3 14:31:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 03 Apr 2015 16:31:03 +0200 Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called with empty array for thread ids Message-ID: <551EA427.3030409@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8074368 Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00 Invoking ThreadMXBean.getThreadInfo(long[] ids, int maxdepth) with an empty array for 'ids' and positive number for 'maxdepth' can result in memory corruption. Basically, the native routine (VM_ThreadDump) considers the empty ids array as a signal to process all the available threads and put their information to the pre-allocated array while the pre-allocated array's size is 0. The solution is to modify 'management.cpp' and check for 'num_threads' before actually attempting to do the thread dump. As a defense-in-depth the ThreadMXBean.getThreadInfo(*) methods are modified to adhere to their specification and return 'an array of the ThreadInfo objects, each containing information about a thread whose ID is in the corresponding element of the input array of IDs' - meaning that an empty ids array will result in an empty ThreadInfo array. Thanks, -JB- From me at basilcrow.com Fri Apr 3 17:27:33 2015 From: me at basilcrow.com (Basil Crow) Date: Fri, 3 Apr 2015 10:27:33 -0700 Subject: Unable to create hprof heap dump from core file with jmap on Oracle Solaris Message-ID: Hi all, I'm having trouble using jmap(1) to create an hprof heap dump from a core file on Oracle Solaris with version 8 of the Oracle JDK. This worked with version 7 of the Oracle JDK: $ cat Sleep.java public class Sleep { public static void main(String[] args) throws InterruptedException { Thread.sleep(300000); } } $ /opt/jdk1.7.0_76/bin/javac Sleep.java $ /opt/jdk1.7.0_76/bin/java Sleep & [1] 1348 $ gcore 1348 gcore: core.1348 dumped $ jmap -dump:format=b,file=core1348.hprof /opt/jdk1.7.0_76/bin/java \ core.1348 Attaching to core core.1348 from executable /opt/jdk1.7.0_76/bin/java Debugger attached successfully. Client compiler detected. JVM version is 24.76-b04 Dumping heap to core1348.hprof ... Heap dump file created This also works with version 8 of the Oracle JDK when lambdas are not used: $ /opt/jdk1.8.0_40/bin/javac Sleep.java $ /opt/jdk1.8.0_40/bin/java Sleep & [1] 1398 $ gcore 1398 gcore: core.1398 dumped $ jmap -dump:format=b,file=core1398.hprof /opt/jdk1.8.0_40/bin/java \ core.1398 Attaching to core core.1398 from executable /opt/jdk1.8.0_40/bin/java Debugger attached successfully. Server compiler detected. JVM version is 25.40-b25 Dumping heap to core1398.hprof ... Heap dump file created However, this no longer works with version 8 of the Oracle JDK when lambdas are used: $ cat LambdaSleep.java import java.util.Arrays; public class LambdaSleep { public static void main(String[] args) throws InterruptedException { String[] words = new String[] { "longer", "short" }; Arrays.sort(words, (first, second) -> Integer.compare(first.length(), second.length())); Thread.sleep(300000); } } $ javac LambdaSleep.java $ java LambdaSleep & [1] 1416 $ gcore 1416 gcore: core.1416 dumped $ jmap -dump:format=b,file=core1416.hprof /opt/jdk1.8.0_40/bin/java \ core.1416 Attaching to core core.1416 from executable /opt/jdk1.8.0_40/bin/java Debugger attached successfully. Server compiler detected. JVM version is 25.40-b25 Dumping heap to core1416.hprof ... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at sun.tools.jmap.JMap.runTool(JMap.java:201) at sun.tools.jmap.JMap.main(JMap.java:130) Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class data for LambdaSleep$$Lambda$10x0000000100071828 at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance( HeapHprofBinWriter.java:803) at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj( AbstractHeapGraphWriter.java:95) at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions( ObjectHeap.java:353) at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171) at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write( AbstractHeapGraphWriter.java:51) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write( HeapHprofBinWriter.java:433) at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83) ... 6 more Note that this problem only occurs when creating an hprof heap dump from a core file. It doesn't occur when creating an hprof heap dump from a live process: $ java LambdaSleep & [1] 1421 $ jmap -dump:format=b,file=core1421.hprof 1421 Dumping heap to core1421.hprof ... Heap dump file created I have reproduced this issue with Java version 1.8.0_40 (JVM version 25.40-b25) on the following platforms: Oracle Solaris 10 9/10 s10x_u9wos_14a X86 Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC Oracle Solaris 11.1 X86 Oracle Solaris 11.2 X86 I found a similar issue in the JDK bug system (JDK-8044416), but the last update there stated that JDK-8044416 "is about the -F functionality" and to "please file a different bug for problems when running without -F." I am running without -F, but I haven't been able to find another bug that tracks the issue described above. An update would be appreciated, as this bug greatly hampers our ability to debug memory leaks in production. Thanks, Basil From dmitry.samersoff at oracle.com Fri Apr 3 21:27:49 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 04 Apr 2015 00:27:49 +0300 Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551D3C0B.3080803@oracle.com> References: <551D3C0B.3080803@oracle.com> Message-ID: <551F05D5.9080601@oracle.com> Everybody, Please, review updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ Fixed a compilation error that wasn't caught during incremental build. -Dmitry On 2015-04-02 15:54, Dmitry Samersoff wrote: > Everybody, > > Please review a small fix: > > The fix goes to 9 and 8u at the same time. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ > > -Dmitry > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Fri Apr 3 21:35:52 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 Apr 2015 14:35:52 -0700 Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called with empty array for thread ids In-Reply-To: <551EA427.3030409@oracle.com> References: <551EA427.3030409@oracle.com> Message-ID: <551F07B8.2010006@oracle.com> On 4/3/15 7:31 AM, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8074368 > Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00 > Looks okay to me. Minor comment on ThreadInfoArray.java test: You can have one single @bug line with multiple bug numbers line 57, 90: can you rename "direct" to mbean? line 59, 92: formatting - indent to the right Mandy From serguei.spitsyn at oracle.com Fri Apr 3 22:52:58 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 03 Apr 2015 15:52:58 -0700 Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551F05D5.9080601@oracle.com> References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com> Message-ID: <551F19CA.4010204@oracle.com> Dmitry, I'm puzzled a little bit with the webrev.02: agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java - buttonSize = new Dimension(CommonUI.buttconPrefSize); + buttonSize = new Dimension(CommonUI.getButtonPrefSize()); Why do you replace the CommonUI.buttconPrefSize with the CommonUI.getButtonPrefSize() ? It looks like a typo, did you really want to do one of the following: - buttonSize = new Dimension(CommonUI.buttconPrefSize); + buttonSize = new Dimension(CommonUI.getButtconPrefSize()); In such a case, the fix must be updated in the agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java + public static Dimension getButtonPrefSize() + { + return buttonPrefSize; + } => + public static Dimension getButtconPrefSize() + { + return buttconPrefSize; + } Thanks, Serguei On 4/3/15 2:27 PM, Dmitry Samersoff wrote: > Everybody, > > Please, review updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ > > Fixed a compilation error that wasn't caught during incremental build. > > -Dmitry > > > > On 2015-04-02 15:54, Dmitry Samersoff wrote: >> Everybody, >> >> Please review a small fix: >> >> The fix goes to 9 and 8u at the same time. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ >> >> -Dmitry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Sat Apr 4 07:06:36 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 04 Apr 2015 10:06:36 +0300 Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551F19CA.4010204@oracle.com> References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com> <551F19CA.4010204@oracle.com> Message-ID: <551F8D7C.7080407@oracle.com> Serguei, Yes, it's a typeo. Time to buy glasses. Thank you for catching it. Webrev updated in-place (press shift-reload). -Dmitry On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I'm puzzled a little bit with the webrev.02: > > agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java > > - buttonSize = new Dimension(CommonUI.buttconPrefSize); > + buttonSize = new Dimension(CommonUI.getButtonPrefSize()); > > > Why do you replace the CommonUI.buttconPrefSize with the > CommonUI.getButtonPrefSize() ? > It looks like a typo, did you really want to do one of the following: > > - buttonSize = new Dimension(CommonUI.buttconPrefSize); > + buttonSize = new Dimension(CommonUI.getButtconPrefSize()); > > > In such a case, the fix must be updated in the > agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java > > + public static Dimension getButtonPrefSize() > + { > + return buttonPrefSize; > + } > > => > > + public static Dimension getButtconPrefSize() > + { > + return buttconPrefSize; > + } > > > > Thanks, > Serguei > > On 4/3/15 2:27 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ >> >> Fixed a compilation error that wasn't caught during incremental build. >> >> -Dmitry >> >> >> >> On 2015-04-02 15:54, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review a small fix: >>> >>> The fix goes to 9 and 8u at the same time. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ >>> >>> -Dmitry >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Sat Apr 4 08:58:34 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 04 Apr 2015 01:58:34 -0700 Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551F8D7C.7080407@oracle.com> References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com> <551F19CA.4010204@oracle.com> <551F8D7C.7080407@oracle.com> Message-ID: <551FA7BA.4020405@oracle.com> Dmitry, I think, no re-review is necessary after fixing this typo. You had addressed the review comments. Thanks, Serguei On 4/4/15 12:06 AM, Dmitry Samersoff wrote: > Serguei, > > Yes, it's a typeo. Time to buy glasses. > > Thank you for catching it. > > Webrev updated in-place (press shift-reload). > > -Dmitry > > > On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> I'm puzzled a little bit with the webrev.02: >> >> agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java >> >> - buttonSize = new Dimension(CommonUI.buttconPrefSize); >> + buttonSize = new Dimension(CommonUI.getButtonPrefSize()); >> >> >> Why do you replace the CommonUI.buttconPrefSize with the >> CommonUI.getButtonPrefSize() ? >> It looks like a typo, did you really want to do one of the following: >> >> - buttonSize = new Dimension(CommonUI.buttconPrefSize); >> + buttonSize = new Dimension(CommonUI.getButtconPrefSize()); >> >> >> In such a case, the fix must be updated in the >> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java >> >> + public static Dimension getButtonPrefSize() >> + { >> + return buttonPrefSize; >> + } >> >> => >> >> + public static Dimension getButtconPrefSize() >> + { >> + return buttconPrefSize; >> + } >> >> >> >> Thanks, >> Serguei >> >> On 4/3/15 2:27 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ >>> >>> Fixed a compilation error that wasn't caught during incremental build. >>> >>> -Dmitry >>> >>> >>> >>> On 2015-04-02 15:54, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review a small fix: >>>> >>>> The fix goes to 9 and 8u at the same time. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ >>>> >>>> -Dmitry >>>> > From dmitry.samersoff at oracle.com Sat Apr 4 09:23:19 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 04 Apr 2015 12:23:19 +0300 Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect In-Reply-To: <551FA7BA.4020405@oracle.com> References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com> <551F19CA.4010204@oracle.com> <551F8D7C.7080407@oracle.com> <551FA7BA.4020405@oracle.com> Message-ID: <551FAD87.6070201@oracle.com> Serguei, Thanks! -Dmitry On 2015-04-04 11:58, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I think, no re-review is necessary after fixing this typo. > You had addressed the review comments. > > Thanks, > Serguei > > On 4/4/15 12:06 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Yes, it's a typeo. Time to buy glasses. >> >> Thank you for catching it. >> >> Webrev updated in-place (press shift-reload). >> >> -Dmitry >> >> >> On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> I'm puzzled a little bit with the webrev.02: >>> >>> agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java >>> >>> - buttonSize = new Dimension(CommonUI.buttconPrefSize); >>> + buttonSize = new Dimension(CommonUI.getButtonPrefSize()); >>> >>> >>> Why do you replace the CommonUI.buttconPrefSize with the >>> CommonUI.getButtonPrefSize() ? >>> It looks like a typo, did you really want to do one of the following: >>> >>> - buttonSize = new Dimension(CommonUI.buttconPrefSize); >>> + buttonSize = new Dimension(CommonUI.getButtconPrefSize()); >>> >>> >>> In such a case, the fix must be updated in the >>> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java >>> >>> + public static Dimension getButtonPrefSize() >>> + { >>> + return buttonPrefSize; >>> + } >>> >>> => >>> >>> + public static Dimension getButtconPrefSize() >>> + { >>> + return buttconPrefSize; >>> + } >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> On 4/3/15 2:27 PM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please, review updated webrev: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ >>>> >>>> Fixed a compilation error that wasn't caught during incremental build. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2015-04-02 15:54, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review a small fix: >>>>> >>>>> The fix goes to 9 and 8u at the same time. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ >>>>> -Dmitry >>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sun Apr 5 08:01:59 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 05 Apr 2015 11:01:59 +0300 Subject: Unable to create hprof heap dump from core file with jmap on Oracle Solaris In-Reply-To: References: Message-ID: <5520EBF7.6030808@oracle.com> Basil, jmap uses SA backend to extract data from coredump and it doesn't support lambda. See JDK-8073604 -Dmitry On 2015-04-03 20:27, Basil Crow wrote: > Hi all, > > I'm having trouble using jmap(1) to create an hprof heap dump from a > core file on Oracle Solaris with version 8 of the Oracle JDK. This > worked with version 7 of the Oracle JDK: > > $ cat Sleep.java > public class Sleep { > public static void main(String[] args) throws InterruptedException { > Thread.sleep(300000); > } > } > $ /opt/jdk1.7.0_76/bin/javac Sleep.java > $ /opt/jdk1.7.0_76/bin/java Sleep & > [1] 1348 > $ gcore 1348 > gcore: core.1348 dumped > $ jmap -dump:format=b,file=core1348.hprof /opt/jdk1.7.0_76/bin/java \ > core.1348 > Attaching to core core.1348 from executable /opt/jdk1.7.0_76/bin/java > Debugger attached successfully. > Client compiler detected. > JVM version is 24.76-b04 > Dumping heap to core1348.hprof ... > Heap dump file created > > This also works with version 8 of the Oracle JDK when lambdas are not > used: > > $ /opt/jdk1.8.0_40/bin/javac Sleep.java > $ /opt/jdk1.8.0_40/bin/java Sleep & > [1] 1398 > $ gcore 1398 > gcore: core.1398 dumped > $ jmap -dump:format=b,file=core1398.hprof /opt/jdk1.8.0_40/bin/java \ > core.1398 > Attaching to core core.1398 from executable /opt/jdk1.8.0_40/bin/java > Debugger attached successfully. > Server compiler detected. > JVM version is 25.40-b25 > Dumping heap to core1398.hprof ... > Heap dump file created > > However, this no longer works with version 8 of the Oracle JDK when > lambdas are used: > > $ cat LambdaSleep.java > import java.util.Arrays; > > public class LambdaSleep { > public static void main(String[] args) throws InterruptedException { > String[] words = new String[] { "longer", "short" }; > Arrays.sort(words, (first, second) -> > Integer.compare(first.length(), second.length())); > Thread.sleep(300000); > } > } > $ javac LambdaSleep.java > $ java LambdaSleep & > [1] 1416 > $ gcore 1416 > gcore: core.1416 dumped > $ jmap -dump:format=b,file=core1416.hprof /opt/jdk1.8.0_40/bin/java \ > core.1416 > Attaching to core core.1416 from executable /opt/jdk1.8.0_40/bin/java > Debugger attached successfully. > Server compiler detected. > JVM version is 25.40-b25 > Dumping heap to core1416.hprof ... > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at sun.tools.jmap.JMap.runTool(JMap.java:201) > at sun.tools.jmap.JMap.main(JMap.java:130) > Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class > data for LambdaSleep$$Lambda$10x0000000100071828 > at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance( > HeapHprofBinWriter.java:803) > at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj( > AbstractHeapGraphWriter.java:95) > at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions( > ObjectHeap.java:353) > at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171) > at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write( > AbstractHeapGraphWriter.java:51) > at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write( > HeapHprofBinWriter.java:433) > at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83) > ... 6 more > > Note that this problem only occurs when creating an hprof heap dump from > a core file. It doesn't occur when creating an hprof heap dump from a > live process: > > $ java LambdaSleep & > [1] 1421 > $ jmap -dump:format=b,file=core1421.hprof 1421 > Dumping heap to core1421.hprof ... > Heap dump file created > > I have reproduced this issue with Java version 1.8.0_40 (JVM version > 25.40-b25) on the following platforms: > > Oracle Solaris 10 9/10 s10x_u9wos_14a X86 > Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC > Oracle Solaris 11.1 X86 > Oracle Solaris 11.2 X86 > > I found a similar issue in the JDK bug system (JDK-8044416), but the > last update there stated that JDK-8044416 "is about the -F > functionality" and to "please file a different bug for problems when > running without -F." I am running without -F, but I haven't been able to > find another bug that tracks the issue described above. > > An update would be appreciated, as this bug greatly hampers our ability > to debug memory leaks in production. > > Thanks, > Basil > -- 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 yasuenag at gmail.com Sun Apr 5 12:49:18 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 05 Apr 2015 21:49:18 +0900 Subject: PING: RFR: JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. In-Reply-To: <5516316B.6000100@gmail.com> References: <5506277B.4000902@oracle.com> <5516316B.6000100@gmail.com> Message-ID: <55212F4E.9080401@gmail.com> Hi all, I need more reviewer. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ Thanks, Yasumasa On 2015/03/28 13:43, Yasumasa Suenaga wrote: > Sorry for the delay. > > I filed it to JBS and uploaded webrev: > > JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. > http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ > > Could you review it? > > >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. > > Thanks, David. > I'll send it to you after reviewing. > > > Yasumasa > > > On 2015?03?16? 09:44, David Holmes wrote: >> On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >>> >>> There are other inline and noinline directives in allocation.hpp. We >>> always assume that AllocateHeap and others are inlined. NMT is touchy >>> with respect to how it walks the stack and it took a bit of work and >>> testing to get just the most useful frames saved. I don't really want >>> to risk this breaking! >>> >>> I think the gcc directive is acceptable in this case. >> >> Okay I'll follow Coleen's guidance on this. The original patch is fine. >> >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. >> >> Thanks, >> David >> >>> Coleen >>> >>> >>> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>>> That would require more significant changes to NMT I think >>>> >>>> I think two changes: >>>> >>>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>>> >>>> I think that caller of AllocateHeap() and ReallocateHeap() should >>>> give >>>> PC to them. >>>> However, it is significant changes. >>>> Thus I proposed to add always_inline . >>>> >>>> >>>>> I don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>> >>>> I think we can use SA. >>>> In case of Linux, >>>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>>> can lookup symbol from target process - we can check whether the >>>> function has been >>>> inlined (cannot lookup) or not (can lookup). >>>> So I think that we can write jtreg testcase. >>>> >>>> BTW, should I file it to JBS? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/03/13 17:35, David Holmes wrote: >>>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>>> Hi Yasumasa, David, >>>>>> >>>>>> Maybe it would make sense to make the >>>>>> number-of-frames-to-skip-parameter >>>>>> configurable? >>>>> >>>>> That would require more significant changes to NMT I think - plus I >>>>> don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>>> not be >>>>>> interesting but still a generic wrapper. So, the user doing the >>>>>> allocation trace could finetune this parameter to fit his needs. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>>> oracle.com >>>>>> > wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried to use NMT with details option on OpenJDK7 on >>>>>> RHEL6.6, >>>>>> but I got >>>>>> address at AllocateHeap() as malloc() caller. >>>>>> >>>>>> I checked symbol in libjvm.so in >>>>>> OracleJDK8u40 Linux >>>>>> x64, it has AllocateHeap() >>>>>> symbol. >>>>>> >>>>>> AllocateHeap() is defined as inline function, and it gives >>>>>> CURRENT_PC to >>>>>> os::malloc(). I guess that implementation expects >>>>>> AllocateHeap() >>>>>> will be >>>>>> inlined. >>>>>> >>>>>> >>>>>> It seems so. >>>>>> >>>>>> It may occur with GCC (g++) optimization only, however I >>>>>> want to >>>>>> fix it to >>>>>> analyze native memory with NMT on Linux. >>>>>> >>>>>> >>>>>> According to the docs [1]: >>>>>> >>>>>> "GCC does not inline any functions when not optimizing unless >>>>>> you >>>>>> specify the ?always_inline? attribute for the function" >>>>>> >>>>>> I applied patch as below. This patch makes AllocateHeap() >>>>>> as >>>>>> inline >>>>>> function. >>>>>> -------------- >>>>>> diff -r af3b0db91659 >>>>>> src/share/vm/memory/__allocation.inline.hpp >>>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar >>>>>> 09 >>>>>> 09:30:16 2015 >>>>>> -0700 >>>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar >>>>>> 12 >>>>>> 20:45:57 2015 >>>>>> +0900 >>>>>> @@ -62,11 +62,18 @@ >>>>>> } >>>>>> return p; >>>>>> } >>>>>> + >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> >>>>>> >>>>>> I dislike seeing the gcc specific directives in common code. >>>>>> I'm >>>>>> wondering whether we should perhaps only use CURRENT_PC in >>>>>> product >>>>>> (and optimized?) builds and use CALLER_PC otherwise. That would >>>>>> be >>>>>> imperfect of course It also makes me wonder whether the >>>>>> inlining is >>>>>> occurring as expected on other platforms. >>>>>> >>>>>> I'd like to get other people's views on this. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>>> >>>>>> >>>>>> >>>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>>> alloc_failmode); >>>>>> } >>>>>> >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> inline char* ReallocateHeap(char *old, size_t size, >>>>>> MEMFLAGS >>>>>> flag, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> char* p = (char*) os::realloc(old, size, flag, >>>>>> CURRENT_PC); >>>>>> -------------- >>>>>> >>>>>> If this patch is accepted, I will file it to JBS and will >>>>>> upload >>>>>> webrev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> From serguei.spitsyn at oracle.com Mon Apr 6 23:50:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 06 Apr 2015 16:50:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <551DD8BB.5040001@oracle.com> References: <551DD8BB.5040001@oracle.com> Message-ID: <55231BAF.3030601@oracle.com> Coleen and Dan, I'm asking you as the jdk 9 reviewers... Please, let me know if you have any chance and plans to review this. Would it be enough to have just one (R) reviewer for a non-clean backport? Thanks, Serguei On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 8u60 backport for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > 8u60 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 > > > 8u60 webrev for unit test update (the fix applies cleanly): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 > > > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 > > > 9 webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 > > > > Summary: > The 9 fix can not be applied cleanly so that I have to rework the > fix a little bit. > > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > Testing in progress: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > From coleen.phillimore at oracle.com Tue Apr 7 01:49:38 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 06 Apr 2015 21:49:38 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55231BAF.3030601@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> Message-ID: <552337B2.2080306@oracle.com> This backport looks good. Why didn't the patch apply cleanly? It seems mostly the same to me. Thanks, Coleen On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen and Dan, > > I'm asking you as the jdk 9 reviewers... > > Please, let me know if you have any chance and plans to review this. > Would it be enough to have just one (R) reviewer for a non-clean > backport? > > Thanks, > Serguei > > > > On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Tue Apr 7 05:09:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 06 Apr 2015 22:09:13 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <552337B2.2080306@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> Message-ID: <55236679.1040807@oracle.com> Coleen, Thank you for looking at this! The main difference is in instanceKlass.cpp and instanceKlass.hpp. 8u60: +Method* InstanceKlass::method_with_orig_idnum(int idnum) { + if (idnum >= methods()->length()) { + return NULL; + } + Method* m = methods()->at(idnum); + if (m != NULL && m->orig_method_idnum() == idnum) { + return m; + } + // Obsolete method idnum does not match the original idnum + for (int index = 0; index < methods()->length(); ++index) { + m = methods()->at(index); + if (m->orig_method_idnum() == idnum) { + return m; + } + } + // None found, return null for the caller to handle. + return NULL; +} + + +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { + if (constants()->version() == version) { + return method_with_orig_idnum(idnum); + } + ConstantPoolCache* cp_cache = NULL; + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); + pv_node != NULL; pv_node = pvw.next_previous_version()) { + ConstantPool* prev_cp = pv_node->prev_constant_pool(); + if (prev_cp->version() == version) { + cp_cache = prev_cp->cache(); + break; + } + } + if (cp_cache == NULL) { + return NULL; // The pv_node is gone, no method is found + } + Method* method = NULL; + for (int i = 0; i < cp_cache->length(); i++) { + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); + method = entry->get_interesting_method_entry(this); + if (method == NULL) { + continue; // skip uninteresting entries + } + if (method->orig_method_idnum() == idnum) { + return method; + } + } + // None found, return null for the caller to handle. + return NULL; +} jdk 9: +Method* InstanceKlass::method_with_orig_idnum(int idnum) { + if (idnum >= methods()->length()) { + return NULL; + } + Method* m = methods()->at(idnum); + if (m != NULL && m->orig_method_idnum() == idnum) { + return m; + } + // Obsolete method idnum does not match the original idnum + for (int index = 0; index < methods()->length(); ++index) { + m = methods()->at(index); + if (m->orig_method_idnum() == idnum) { + return m; + } + } + // None found, return null for the caller to handle. + return NULL; +} + + +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { + InstanceKlass* holder = get_klass_version(version); + if (holder == NULL) { + return NULL; // The version of klass is gone, no method is found + } + Method* method = holder->method_with_orig_idnum(idnum); + return method; +} Thanks, Serguei On 4/6/15 6:49 PM, Coleen Phillimore wrote: > > This backport looks good. Why didn't the patch apply cleanly? It > seems mostly the same to me. > Thanks, > Coleen > > On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >> Coleen and Dan, >> >> I'm asking you as the jdk 9 reviewers... >> >> Please, let me know if you have any chance and plans to review this. >> Would it be enough to have just one (R) reviewer for a non-clean >> backport? >> >> Thanks, >> Serguei >> >> >> >> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 8u60 backport for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> 8u60 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>> >>> >>> 8u60 webrev for unit test update (the fix applies cleanly): >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>> >>> >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>> >>> >>> 9 webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>> >>> >>> >>> Summary: >>> The 9 fix can not be applied cleanly so that I have to rework the >>> fix a little bit. >>> >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> Testing in progress: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Apr 7 12:52:59 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 07 Apr 2015 14:52:59 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <551D39B4.70506@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> Message-ID: <5523D32B.1080406@oracle.com> Hi, The updated webrev can be found here: http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/ Thanks, Katja On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: > Hi Katja, > > On 2.4.2015 14:16, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ > > In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would > suggest adding System.out.flush() after printing "jstatd is started on > ..." to make sure the output is actually committed to stdout. > > Please, update the copyright years. > > -JB- > >> >> The tests can still contain a race. There is a possibility the jstad is >> not really started though there is a pid for the process. The suggestion >> is to let jstatd notify it's started and for the test wait until this >> notification. >> >> Thanks, >> Katja > From staffan.larsen at oracle.com Tue Apr 7 13:03:09 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Apr 2015 15:03:09 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <5523D32B.1080406@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> <5523D32B.1080406@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 7 apr 2015, at 14:52, Yekaterina Kantserova wrote: > > Hi, > > The updated webrev can be found here: http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/ > > Thanks, > Katja > > > > On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> On 2.4.2015 14:16, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ >> >> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout. >> >> Please, update the copyright years. >> >> -JB- >> >>> >>> The tests can still contain a race. There is a possibility the jstad is >>> not really started though there is a pid for the process. The suggestion >>> is to let jstatd notify it's started and for the test wait until this >>> notification. >>> >>> Thanks, >>> Katja >> > From jaroslav.bachorik at oracle.com Tue Apr 7 13:55:56 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 07 Apr 2015 15:55:56 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <5523D32B.1080406@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> <5523D32B.1080406@oracle.com> Message-ID: <5523E1EC.6080608@oracle.com> Looks fine! You might want to convert the 'jstatd started (bound to' string to a constant to make it easier to track any changes in the future but it is up to you. I am fine with the changes anyway. -JB- On 7.4.2015 14:52, Yekaterina Kantserova wrote: > Hi, > > The updated webrev can be found here: > http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/ > > Thanks, > Katja > > > > On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> On 2.4.2015 14:16, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ >> >> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would >> suggest adding System.out.flush() after printing "jstatd is started on >> ..." to make sure the output is actually committed to stdout. >> >> Please, update the copyright years. >> >> -JB- >> >>> >>> The tests can still contain a race. There is a possibility the jstad is >>> not really started though there is a pid for the process. The suggestion >>> is to let jstatd notify it's started and for the test wait until this >>> notification. >>> >>> Thanks, >>> Katja >> > From yekaterina.kantserova at oracle.com Tue Apr 7 14:28:13 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 07 Apr 2015 16:28:13 +0200 Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect In-Reply-To: <5523E1EC.6080608@oracle.com> References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com> <5523D32B.1080406@oracle.com> <5523E1EC.6080608@oracle.com> Message-ID: <5523E97D.8030409@oracle.com> Jaroslav, Staffan, Thanks for the reviews! // Katja On 04/07/2015 03:55 PM, Jaroslav Bachorik wrote: > Looks fine! > > You might want to convert the 'jstatd started (bound to' string to a > constant to make it easier to track any changes in the future but it > is up to you. I am fine with the changes anyway. > > -JB- > > > On 7.4.2015 14:52, Yekaterina Kantserova wrote: >> Hi, >> >> The updated webrev can be found here: >> http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/ >> >> Thanks, >> Katja >> >> >> >> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote: >>> Hi Katja, >>> >>> On 2.4.2015 14:16, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/ >>> >>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would >>> suggest adding System.out.flush() after printing "jstatd is started on >>> ..." to make sure the output is actually committed to stdout. >>> >>> Please, update the copyright years. >>> >>> -JB- >>> >>>> >>>> The tests can still contain a race. There is a possibility the >>>> jstad is >>>> not really started though there is a pid for the process. The >>>> suggestion >>>> is to let jstatd notify it's started and for the test wait until this >>>> notification. >>>> >>>> Thanks, >>>> Katja >>> >> > From erik.joelsson at oracle.com Tue Apr 7 15:15:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 Apr 2015 17:15:56 +0200 Subject: RFR Message-ID: <5523F4AC.9050007@oracle.com> Hello, When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away. Bug: https://bugs.openjdk.java.net/browse/JDK-8076557 Patch inline: diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100 +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200 @@ -38,6 +38,11 @@ $(LIBJAVA_HEADER_FLAGS) \ # +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate +# a binary that is compatible with windows versions older than 7/2008R2. +# See MSDN documentation for GetProcessMemoryInfo for more information. +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 + BUILD_LIBMANAGEMENT_EXCLUDES := ifneq ($(OPENJDK_TARGET_OS), solaris) /Erik From erik.joelsson at oracle.com Tue Apr 7 15:21:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 Apr 2015 17:21:02 +0200 Subject: RFR: JDK-8076557: The specified procedure could not be found in management.dll In-Reply-To: <5523F4AC.9050007@oracle.com> References: <5523F4AC.9050007@oracle.com> Message-ID: <5523F5DE.9030601@oracle.com> (corrected subject) On 2015-04-07 17:15, Erik Joelsson wrote: > Hello, > > When upgrading the toolchain to VS2013, management.dll stopped working > on certain Windows hosts. I've identified this to be related to the > call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, > the problem goes away. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076557 > Patch inline: > > diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk > --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100 > +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200 > @@ -38,6 +38,11 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to > generate > +# a binary that is compatible with windows versions older than 7/2008R2. > +# See MSDN documentation for GetProcessMemoryInfo for more information. > +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 > + > BUILD_LIBMANAGEMENT_EXCLUDES := > > ifneq ($(OPENJDK_TARGET_OS), solaris) > > > /Erik From jaroslav.bachorik at oracle.com Tue Apr 7 16:06:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 07 Apr 2015 18:06:02 +0200 Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called with empty array for thread ids In-Reply-To: <551F07B8.2010006@oracle.com> References: <551EA427.3030409@oracle.com> <551F07B8.2010006@oracle.com> Message-ID: <5524006A.4070109@oracle.com> Hi Mandy, On 3.4.2015 23:35, Mandy Chung wrote: > On 4/3/15 7:31 AM, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8074368 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00 >> > Looks okay to me. > > Minor comment on ThreadInfoArray.java test: > You can have one single @bug line with multiple bug numbers > line 57, 90: can you rename "direct" to mbean? > line 59, 92: formatting - indent to the right Only the test parts updated - http://cr.openjdk.java.net/~jbachorik/8074368/webrev.01/ -JB- > > Mandy > > From daniel.daugherty at oracle.com Tue Apr 7 16:44:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:44:37 -0600 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55135DE5.2010705@oracle.com> References: <55135DE5.2010705@oracle.com> Message-ID: <55240975.4080009@oracle.com> On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8066679 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ > src/share/vm/prims/jvmtiRedefineClasses.cpp I concur that the old assertions are bad. They assume that the cached class file bytes on the scratch_class must match the cached class file bytes on the target class. That's a valid assumption in a RedefineClasses() only world, but that's not true when RetransformClasses() is used. This will be hard to test. I think the race can only happen on the first retransform of a class. If you have two parallel retransform threads, both see that there are no cached bytes so both cache the initial bytes and then both have to update the cached bytes pointer at about the same time... Very hard to do... Thumbs up. Dan > > > Summary: > > There can be multiple concurrent RetransformClasses calls on > different threads. > So that, the assert "cache ptrs must match" is incorrect as it was > based on wrong assumptions. > The fix removes two related asserts and also frees the scratch_class > cached_class_file_bytes > if it is necessary to avoid leaking the memory. > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > From daniel.daugherty at oracle.com Tue Apr 7 16:54:34 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:54:34 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <551DD8BB.5040001@oracle.com> References: <551DD8BB.5040001@oracle.com> Message-ID: <55240BC9.8070500@oracle.com> On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 8u60 backport for: > https://bugs.openjdk.java.net/browse/JDK-8067662 > > 8u60 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 > Nit - please update copyright years as needed before you push. src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. Thumbs up. Dan > > 8u60 webrev for unit test update (the fix applies cleanly): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 > > > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 > > > 9 webrev for unit test update: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 > > > > Summary: > The 9 fix can not be applied cleanly so that I have to rework the > fix a little bit. > > An NPE is trown in a thread dumping via JMX when doing CPU profiling > in NetBeans Profiler and VisualVM. > The issue is that the methods and related klass versions are not > kept alive if a class redefinition > takes place between catching a Throwable and taking a thread dump. > It can result in loosing an obsolete method, and so, the > reconstruction of method name becomes impossible. > In such a case, the null reference is returned instead of a valid > method name. > > The solution is to use current klass version and method orig_idnum > instead of ordinary method idnum > to find required method pointer. In the worst case when the related > klass version is gone > (was not included to or was removed from the previous_versions > linked list), a saved method name > CP index of the latest klass version can be used to restore the > method name. > The footprint extra overhead for this approach is u2 per stack frame. > > Testing in progress: > In progress: nsk redefine classes tests, JTREG java/lang/instrument > > > Thanks, > Serguei > > > From daniel.daugherty at oracle.com Tue Apr 7 16:59:54 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 Apr 2015 10:59:54 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55231BAF.3030601@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> Message-ID: <55240D0A.7000801@oracle.com> I _think_ you're OK with a single (R)eviewer for a backport even when minor changes are required, but I can never remember all these rules for sure... Dan On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen and Dan, > > I'm asking you as the jdk 9 reviewers... > > Please, let me know if you have any chance and plans to review this. > Would it be enough to have just one (R) reviewer for a non-clean > backport? > > Thanks, > Serguei > > > > On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > > From tim.bell at oracle.com Tue Apr 7 17:08:37 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 07 Apr 2015 10:08:37 -0700 Subject: RFR: JDK-8076557: The specified procedure could not be found in management.dll In-Reply-To: <5523F5DE.9030601@oracle.com> References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com> Message-ID: <55240F15.7060406@oracle.com> Erik- Looks good to me. Tim On 04/07/15 08:21, Erik Joelsson wrote: > (corrected subject) > > On 2015-04-07 17:15, Erik Joelsson wrote: >> Hello, >> >> When upgrading the toolchain to VS2013, management.dll stopped >> working on certain Windows hosts. I've identified this to be related >> to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to >> CFLAGS, the problem goes away. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557 >> Patch inline: >> >> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk >> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100 >> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200 >> @@ -38,6 +38,11 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to >> generate >> +# a binary that is compatible with windows versions older than >> 7/2008R2. >> +# See MSDN documentation for GetProcessMemoryInfo for more information. >> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >> + >> BUILD_LIBMANAGEMENT_EXCLUDES := >> >> ifneq ($(OPENJDK_TARGET_OS), solaris) >> >> >> /Erik > From coleen.phillimore at oracle.com Tue Apr 7 18:20:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 07 Apr 2015 14:20:39 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55236679.1040807@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> Message-ID: <55241FF7.3060801@oracle.com> I see. The PreviousVersionWalker is gone in 9 and you're using it to find the method. But this is only going to find the method if it happens to be in the cpCache somewhere. I think pv_node->prev_constant_pool()->pool_holder() is scratch_class (not 100% sure). In which case, you can look at that class to find the method with idnum. Coleen On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for looking at this! > > The main difference is in instanceKlass.cpp and instanceKlass.hpp. > > 8u60: > +Method* InstanceKlass::method_with_orig_idnum(int idnum) { > + if (idnum >= methods()->length()) { > + return NULL; > + } > + Method* m = methods()->at(idnum); > + if (m != NULL && m->orig_method_idnum() == idnum) { > + return m; > + } > + // Obsolete method idnum does not match the original idnum > + for (int index = 0; index < methods()->length(); ++index) { > + m = methods()->at(index); > + if (m->orig_method_idnum() == idnum) { > + return m; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > + > + > +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { > + if (constants()->version() == version) { > + return method_with_orig_idnum(idnum); > + } > + ConstantPoolCache* cp_cache = NULL; > + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); > + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); > + pv_node != NULL; pv_node = pvw.next_previous_version()) { > + ConstantPool* prev_cp = pv_node->prev_constant_pool(); > + if (prev_cp->version() == version) { > + cp_cache = prev_cp->cache(); > + break; > + } > + } > + if (cp_cache == NULL) { > + return NULL; // The pv_node is gone, no method is found > + } > + Method* method = NULL; > + for (int i = 0; i < cp_cache->length(); i++) { > + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); > + method = entry->get_interesting_method_entry(this); > + if (method == NULL) { > + continue; // skip uninteresting entries > + } > + if (method->orig_method_idnum() == idnum) { > + return method; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > > > jdk 9: > > +Method* InstanceKlass::method_with_orig_idnum(int idnum) { > + if (idnum >= methods()->length()) { > + return NULL; > + } > + Method* m = methods()->at(idnum); > + if (m != NULL && m->orig_method_idnum() == idnum) { > + return m; > + } > + // Obsolete method idnum does not match the original idnum > + for (int index = 0; index < methods()->length(); ++index) { > + m = methods()->at(index); > + if (m->orig_method_idnum() == idnum) { > + return m; > + } > + } > + // None found, return null for the caller to handle. > + return NULL; > +} > + > + > +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { > + InstanceKlass* holder = get_klass_version(version); > + if (holder == NULL) { > + return NULL; // The version of klass is gone, no method is found > + } > + Method* method = holder->method_with_orig_idnum(idnum); > + return method; > +} > > > Thanks, > Serguei > > > On 4/6/15 6:49 PM, Coleen Phillimore wrote: >> >> This backport looks good. Why didn't the patch apply cleanly? It >> seems mostly the same to me. >> Thanks, >> Coleen >> >> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>> Coleen and Dan, >>> >>> I'm asking you as the jdk 9 reviewers... >>> >>> Please, let me know if you have any chance and plans to review this. >>> Would it be enough to have just one (R) reviewer for a non-clean >>> backport? >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the jdk 8u60 backport for: >>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>> >>>> 8u60 hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>> >>>> >>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>> >>>> >>>> >>>> >>>> 9 hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>> >>>> >>>> 9 webrev for unit test update: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>> >>>> >>>> >>>> Summary: >>>> The 9 fix can not be applied cleanly so that I have to rework the >>>> fix a little bit. >>>> >>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>> profiling in NetBeans Profiler and VisualVM. >>>> The issue is that the methods and related klass versions are not >>>> kept alive if a class redefinition >>>> takes place between catching a Throwable and taking a thread dump. >>>> It can result in loosing an obsolete method, and so, the >>>> reconstruction of method name becomes impossible. >>>> In such a case, the null reference is returned instead of a valid >>>> method name. >>>> >>>> The solution is to use current klass version and method >>>> orig_idnum instead of ordinary method idnum >>>> to find required method pointer. In the worst case when the >>>> related klass version is gone >>>> (was not included to or was removed from the previous_versions >>>> linked list), a saved method name >>>> CP index of the latest klass version can be used to restore the >>>> method name. >>>> The footprint extra overhead for this approach is u2 per stack >>>> frame. >>>> >>>> Testing in progress: >>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Apr 7 18:49:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 7 Apr 2015 20:49:06 +0200 Subject: RFR In-Reply-To: <5523F4AC.9050007@oracle.com> References: <5523F4AC.9050007@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 7 apr 2015, at 17:15, Erik Joelsson wrote: > > Hello, > > When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076557 > Patch inline: > > diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk > --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100 > +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200 > @@ -38,6 +38,11 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate > +# a binary that is compatible with windows versions older than 7/2008R2. > +# See MSDN documentation for GetProcessMemoryInfo for more information. > +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 > + > BUILD_LIBMANAGEMENT_EXCLUDES := > > ifneq ($(OPENJDK_TARGET_OS), solaris) > > > /Erik From mandy.chung at oracle.com Tue Apr 7 19:00:44 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 07 Apr 2015 12:00:44 -0700 Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called with empty array for thread ids In-Reply-To: <5524006A.4070109@oracle.com> References: <551EA427.3030409@oracle.com> <551F07B8.2010006@oracle.com> <5524006A.4070109@oracle.com> Message-ID: <5524295C.10606@oracle.com> On 4/7/15 9:06 AM, Jaroslav Bachorik wrote: > Hi Mandy, > > On 3.4.2015 23:35, Mandy Chung wrote: >> On 4/3/15 7:31 AM, Jaroslav Bachorik wrote: >>> Please, review the following change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8074368 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00 >>> >> Looks okay to me. >> >> Minor comment on ThreadInfoArray.java test: >> You can have one single @bug line with multiple bug numbers >> line 57, 90: can you rename "direct" to mbean? >> line 59, 92: formatting - indent to the right > > Only the test parts updated - > http://cr.openjdk.java.net/~jbachorik/8074368/webrev.01/ > Looks good. thanks Mandy From serguei.spitsyn at oracle.com Tue Apr 7 20:14:18 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:14:18 -0700 Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match In-Reply-To: <55240975.4080009@oracle.com> References: <55135DE5.2010705@oracle.com> <55240975.4080009@oracle.com> Message-ID: <55243A9A.6060603@oracle.com> Great Thanks, Dan! Serguei On 4/7/15 9:44 AM, Daniel D. Daugherty wrote: > On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8066679 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/ >> > > src/share/vm/prims/jvmtiRedefineClasses.cpp > I concur that the old assertions are bad. They assume that > the cached class file bytes on the scratch_class must match > the cached class file bytes on the target class. That's a > valid assumption in a RedefineClasses() only world, but that's > not true when RetransformClasses() is used. > > This will be hard to test. I think the race can only happen > on the first retransform of a class. If you have two parallel > retransform threads, both see that there are no cached bytes > so both cache the initial bytes and then both have to update > the cached bytes pointer at about the same time... Very hard > to do... > > Thumbs up. > > Dan > > >> >> >> Summary: >> >> There can be multiple concurrent RetransformClasses calls on >> different threads. >> So that, the assert "cache ptrs must match" is incorrect as it was >> based on wrong assumptions. >> The fix removes two related asserts and also frees the >> scratch_class cached_class_file_bytes >> if it is necessary to avoid leaking the memory. >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Tue Apr 7 20:15:37 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:15:37 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55240BC9.8070500@oracle.com> References: <551DD8BB.5040001@oracle.com> <55240BC9.8070500@oracle.com> Message-ID: <55243AE9.9090502@oracle.com> Dan, thank you for the review! On 4/7/15 9:54 AM, Daniel D. Daugherty wrote: > On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 8u60 backport for: >> https://bugs.openjdk.java.net/browse/JDK-8067662 >> >> 8u60 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >> > > Nit - please update copyright years as needed before you push. Sure, that's the plan. Thanks, Serguei > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > > Thumbs up. > > Dan > > > > >> >> 8u60 webrev for unit test update (the fix applies cleanly): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >> >> >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >> >> >> 9 webrev for unit test update: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >> >> >> >> Summary: >> The 9 fix can not be applied cleanly so that I have to rework the >> fix a little bit. >> >> An NPE is trown in a thread dumping via JMX when doing CPU >> profiling in NetBeans Profiler and VisualVM. >> The issue is that the methods and related klass versions are not >> kept alive if a class redefinition >> takes place between catching a Throwable and taking a thread dump. >> It can result in loosing an obsolete method, and so, the >> reconstruction of method name becomes impossible. >> In such a case, the null reference is returned instead of a valid >> method name. >> >> The solution is to use current klass version and method orig_idnum >> instead of ordinary method idnum >> to find required method pointer. In the worst case when the related >> klass version is gone >> (was not included to or was removed from the previous_versions >> linked list), a saved method name >> CP index of the latest klass version can be used to restore the >> method name. >> The footprint extra overhead for this approach is u2 per stack frame. >> >> Testing in progress: >> In progress: nsk redefine classes tests, JTREG java/lang/instrument >> >> >> Thanks, >> Serguei >> >> >> > From serguei.spitsyn at oracle.com Tue Apr 7 20:17:28 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 13:17:28 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55240D0A.7000801@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <55240D0A.7000801@oracle.com> Message-ID: <55243B58.8040709@oracle.com> Ok, thanks! Serguei On 4/7/15 9:59 AM, Daniel D. Daugherty wrote: > I _think_ you're OK with a single (R)eviewer for a backport even > when minor changes are required, but I can never remember all these > rules for sure... > > Dan > > > On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote: >> Coleen and Dan, >> >> I'm asking you as the jdk 9 reviewers... >> >> Please, let me know if you have any chance and plans to review this. >> Would it be enough to have just one (R) reviewer for a non-clean >> backport? >> >> Thanks, >> Serguei >> >> >> >> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 8u60 backport for: >>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>> >>> 8u60 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>> >>> >>> 8u60 webrev for unit test update (the fix applies cleanly): >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>> >>> >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>> >>> >>> 9 webrev for unit test update: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>> >>> >>> >>> Summary: >>> The 9 fix can not be applied cleanly so that I have to rework the >>> fix a little bit. >>> >>> An NPE is trown in a thread dumping via JMX when doing CPU >>> profiling in NetBeans Profiler and VisualVM. >>> The issue is that the methods and related klass versions are not >>> kept alive if a class redefinition >>> takes place between catching a Throwable and taking a thread dump. >>> It can result in loosing an obsolete method, and so, the >>> reconstruction of method name becomes impossible. >>> In such a case, the null reference is returned instead of a valid >>> method name. >>> >>> The solution is to use current klass version and method orig_idnum >>> instead of ordinary method idnum >>> to find required method pointer. In the worst case when the >>> related klass version is gone >>> (was not included to or was removed from the previous_versions >>> linked list), a saved method name >>> CP index of the latest klass version can be used to restore the >>> method name. >>> The footprint extra overhead for this approach is u2 per stack frame. >>> >>> Testing in progress: >>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >>> >> >> > From serguei.spitsyn at oracle.com Tue Apr 7 21:01:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 14:01:35 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55241FF7.3060801@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> Message-ID: <552445AF.50209@oracle.com> On 4/7/15 11:20 AM, Coleen Phillimore wrote: > > ?I see. The PreviousVersionWalker is gone in 9 and you're using it to > find the method. > > But this is only going to find the method if it happens to be in the > cpCache somewhere. I think > pv_node->prev_constant_pool()->pool_holder() is scratch_class (not > 100% sure). In which case, you can look at that class to find the > method with idnum. I'm not 100% sure either. Ok, I will check if using the prev_constant_pool()->pool_holder() is going to work. It'd make it more consistent with the jdk 9 fix. Important part is that at least the saved cpref can be used to find method name in the the_class cpool if the attempt to find in the previous list cpCaches was unsuccessful. Thanks, Serguei > > Coleen > > On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Thank you for looking at this! >> >> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >> >> 8u60: >> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >> + if (idnum >= methods()->length()) { >> + return NULL; >> + } >> + Method* m = methods()->at(idnum); >> + if (m != NULL && m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + // Obsolete method idnum does not match the original idnum >> + for (int index = 0; index < methods()->length(); ++index) { >> + m = methods()->at(index); >> + if (m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> + >> + >> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >> + if (constants()->version() == version) { >> + return method_with_orig_idnum(idnum); >> + } >> + ConstantPoolCache* cp_cache = NULL; >> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >> + if (prev_cp->version() == version) { >> + cp_cache = prev_cp->cache(); >> + break; >> + } >> + } >> + if (cp_cache == NULL) { >> + return NULL; // The pv_node is gone, no method is found >> + } >> + Method* method = NULL; >> + for (int i = 0; i < cp_cache->length(); i++) { >> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >> + method = entry->get_interesting_method_entry(this); >> + if (method == NULL) { >> + continue; // skip uninteresting entries >> + } >> + if (method->orig_method_idnum() == idnum) { >> + return method; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> >> >> jdk 9: >> >> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >> + if (idnum >= methods()->length()) { >> + return NULL; >> + } >> + Method* m = methods()->at(idnum); >> + if (m != NULL && m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + // Obsolete method idnum does not match the original idnum >> + for (int index = 0; index < methods()->length(); ++index) { >> + m = methods()->at(index); >> + if (m->orig_method_idnum() == idnum) { >> + return m; >> + } >> + } >> + // None found, return null for the caller to handle. >> + return NULL; >> +} >> + >> + >> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >> + InstanceKlass* holder = get_klass_version(version); >> + if (holder == NULL) { >> + return NULL; // The version of klass is gone, no method is found >> + } >> + Method* method = holder->method_with_orig_idnum(idnum); >> + return method; >> +} >> >> >> Thanks, >> Serguei >> >> >> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>> >>> This backport looks good. Why didn't the patch apply cleanly? It >>> seems mostly the same to me. >>> Thanks, >>> Coleen >>> >>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>> Coleen and Dan, >>>> >>>> I'm asking you as the jdk 9 reviewers... >>>> >>>> Please, let me know if you have any chance and plans to review this. >>>> Would it be enough to have just one (R) reviewer for a non-clean >>>> backport? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the jdk 8u60 backport for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>> >>>>> 8u60 hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>> >>>>> >>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>> >>>>> >>>>> >>>>> >>>>> 9 hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>> >>>>> >>>>> 9 webrev for unit test update: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>> >>>>> >>>>> >>>>> Summary: >>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>> the fix a little bit. >>>>> >>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>> profiling in NetBeans Profiler and VisualVM. >>>>> The issue is that the methods and related klass versions are not >>>>> kept alive if a class redefinition >>>>> takes place between catching a Throwable and taking a thread dump. >>>>> It can result in loosing an obsolete method, and so, the >>>>> reconstruction of method name becomes impossible. >>>>> In such a case, the null reference is returned instead of a >>>>> valid method name. >>>>> >>>>> The solution is to use current klass version and method >>>>> orig_idnum instead of ordinary method idnum >>>>> to find required method pointer. In the worst case when the >>>>> related klass version is gone >>>>> (was not included to or was removed from the previous_versions >>>>> linked list), a saved method name >>>>> CP index of the latest klass version can be used to restore the >>>>> method name. >>>>> The footprint extra overhead for this approach is u2 per stack >>>>> frame. >>>>> >>>>> Testing in progress: >>>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 8 01:07:57 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 18:07:57 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <552445AF.50209@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> Message-ID: <55247F6D.5090003@oracle.com> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: > On 4/7/15 11:20 AM, Coleen Phillimore wrote: >> >> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >> to find the method. >> >> But this is only going to find the method if it happens to be in the >> cpCache somewhere. I think >> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >> 100% sure). In which case, you can look at that class to find the >> method with idnum. > I'm not 100% sure either. > Ok, I will check if using the prev_constant_pool()->pool_holder() is > going to work. > It'd make it more consistent with the jdk 9 fix. This is the updated webrev. It is more consistent with the jdk 9 fix. Thank you for the suggestion! Thanks, Serguei > > Important part is that at least the saved cpref can be used to find > method name in the > the_class cpool if the attempt to find in the previous list cpCaches > was unsuccessful. > > Thanks, > Serguei > >> >> Coleen >> >> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> Thank you for looking at this! >>> >>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>> >>> 8u60: >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>> + if (idnum >= methods()->length()) { >>> + return NULL; >>> + } >>> + Method* m = methods()->at(idnum); >>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + // Obsolete method idnum does not match the original idnum >>> + for (int index = 0; index < methods()->length(); ++index) { >>> + m = methods()->at(index); >>> + if (m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> + >>> + >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>> + if (constants()->version() == version) { >>> + return method_with_orig_idnum(idnum); >>> + } >>> + ConstantPoolCache* cp_cache = NULL; >>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>> + if (prev_cp->version() == version) { >>> + cp_cache = prev_cp->cache(); >>> + break; >>> + } >>> + } >>> + if (cp_cache == NULL) { >>> + return NULL; // The pv_node is gone, no method is found >>> + } >>> + Method* method = NULL; >>> + for (int i = 0; i < cp_cache->length(); i++) { >>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>> + method = entry->get_interesting_method_entry(this); >>> + if (method == NULL) { >>> + continue; // skip uninteresting entries >>> + } >>> + if (method->orig_method_idnum() == idnum) { >>> + return method; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> >>> >>> jdk 9: >>> >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>> + if (idnum >= methods()->length()) { >>> + return NULL; >>> + } >>> + Method* m = methods()->at(idnum); >>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + // Obsolete method idnum does not match the original idnum >>> + for (int index = 0; index < methods()->length(); ++index) { >>> + m = methods()->at(index); >>> + if (m->orig_method_idnum() == idnum) { >>> + return m; >>> + } >>> + } >>> + // None found, return null for the caller to handle. >>> + return NULL; >>> +} >>> + >>> + >>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>> + InstanceKlass* holder = get_klass_version(version); >>> + if (holder == NULL) { >>> + return NULL; // The version of klass is gone, no method is found >>> + } >>> + Method* method = holder->method_with_orig_idnum(idnum); >>> + return method; >>> +} >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>> >>>> This backport looks good. Why didn't the patch apply cleanly? It >>>> seems mostly the same to me. >>>> Thanks, >>>> Coleen >>>> >>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen and Dan, >>>>> >>>>> I'm asking you as the jdk 9 reviewers... >>>>> >>>>> Please, let me know if you have any chance and plans to review this. >>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>> backport? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the jdk 8u60 backport for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>> >>>>>> 8u60 hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>> >>>>>> >>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 9 hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>> >>>>>> >>>>>> 9 webrev for unit test update: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>> the fix a little bit. >>>>>> >>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>> The issue is that the methods and related klass versions are >>>>>> not kept alive if a class redefinition >>>>>> takes place between catching a Throwable and taking a thread dump. >>>>>> It can result in loosing an obsolete method, and so, the >>>>>> reconstruction of method name becomes impossible. >>>>>> In such a case, the null reference is returned instead of a >>>>>> valid method name. >>>>>> >>>>>> The solution is to use current klass version and method >>>>>> orig_idnum instead of ordinary method idnum >>>>>> to find required method pointer. In the worst case when the >>>>>> related klass version is gone >>>>>> (was not included to or was removed from the previous_versions >>>>>> linked list), a saved method name >>>>>> CP index of the latest klass version can be used to restore the >>>>>> method name. >>>>>> The footprint extra overhead for this approach is u2 per stack >>>>>> frame. >>>>>> >>>>>> Testing in progress: >>>>>> In progress: nsk redefine classes tests, JTREG >>>>>> java/lang/instrument >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 8 01:09:31 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 07 Apr 2015 18:09:31 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55247F6D.5090003@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> Message-ID: <55247FCB.6050000@oracle.com> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: > > > On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>> >>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >>> to find the method. >>> >>> But this is only going to find the method if it happens to be in the >>> cpCache somewhere. I think >>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>> 100% sure). In which case, you can look at that class to find the >>> method with idnum. >> I'm not 100% sure either. >> Ok, I will check if using the prev_constant_pool()->pool_holder() is >> going to work. >> It'd make it more consistent with the jdk 9 fix. > > This is the updated webrev. Sorry, forgot to paste the link: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ Thanks, Serguei > It is more consistent with the jdk 9 fix. > Thank you for the suggestion! > > Thanks, > Serguei > >> >> Important part is that at least the saved cpref can be used to find >> method name in the >> the_class cpool if the attempt to find in the previous list cpCaches >> was unsuccessful. >> >> Thanks, >> Serguei >> >>> >>> Coleen >>> >>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> Thank you for looking at this! >>>> >>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>> >>>> 8u60: >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>> + if (idnum >= methods()->length()) { >>>> + return NULL; >>>> + } >>>> + Method* m = methods()->at(idnum); >>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + // Obsolete method idnum does not match the original idnum >>>> + for (int index = 0; index < methods()->length(); ++index) { >>>> + m = methods()->at(index); >>>> + if (m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> + >>>> + >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>> + if (constants()->version() == version) { >>>> + return method_with_orig_idnum(idnum); >>>> + } >>>> + ConstantPoolCache* cp_cache = NULL; >>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>> + if (prev_cp->version() == version) { >>>> + cp_cache = prev_cp->cache(); >>>> + break; >>>> + } >>>> + } >>>> + if (cp_cache == NULL) { >>>> + return NULL; // The pv_node is gone, no method is found >>>> + } >>>> + Method* method = NULL; >>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>> + method = entry->get_interesting_method_entry(this); >>>> + if (method == NULL) { >>>> + continue; // skip uninteresting entries >>>> + } >>>> + if (method->orig_method_idnum() == idnum) { >>>> + return method; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> >>>> >>>> jdk 9: >>>> >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>> + if (idnum >= methods()->length()) { >>>> + return NULL; >>>> + } >>>> + Method* m = methods()->at(idnum); >>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + // Obsolete method idnum does not match the original idnum >>>> + for (int index = 0; index < methods()->length(); ++index) { >>>> + m = methods()->at(index); >>>> + if (m->orig_method_idnum() == idnum) { >>>> + return m; >>>> + } >>>> + } >>>> + // None found, return null for the caller to handle. >>>> + return NULL; >>>> +} >>>> + >>>> + >>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>> + InstanceKlass* holder = get_klass_version(version); >>>> + if (holder == NULL) { >>>> + return NULL; // The version of klass is gone, no method is found >>>> + } >>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>> + return method; >>>> +} >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>> >>>>> This backport looks good. Why didn't the patch apply cleanly? It >>>>> seems mostly the same to me. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen and Dan, >>>>>> >>>>>> I'm asking you as the jdk 9 reviewers... >>>>>> >>>>>> Please, let me know if you have any chance and plans to review this. >>>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>>> backport? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the jdk 8u60 backport for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>> >>>>>>> 8u60 hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>> >>>>>>> >>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 9 hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>> >>>>>>> >>>>>>> 9 webrev for unit test update: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>>> the fix a little bit. >>>>>>> >>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>> The issue is that the methods and related klass versions are >>>>>>> not kept alive if a class redefinition >>>>>>> takes place between catching a Throwable and taking a thread >>>>>>> dump. >>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>> reconstruction of method name becomes impossible. >>>>>>> In such a case, the null reference is returned instead of a >>>>>>> valid method name. >>>>>>> >>>>>>> The solution is to use current klass version and method >>>>>>> orig_idnum instead of ordinary method idnum >>>>>>> to find required method pointer. In the worst case when the >>>>>>> related klass version is gone >>>>>>> (was not included to or was removed from the previous_versions >>>>>>> linked list), a saved method name >>>>>>> CP index of the latest klass version can be used to restore >>>>>>> the method name. >>>>>>> The footprint extra overhead for this approach is u2 per stack >>>>>>> frame. >>>>>>> >>>>>>> Testing in progress: >>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>> java/lang/instrument >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Apr 8 06:39:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 8 Apr 2015 08:39:46 +0200 Subject: RFR: JDK-8076557: The specified procedure could not be found in management.dll In-Reply-To: <5523F5DE.9030601@oracle.com> References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com> Message-ID: Looks good to me. /Magnus > 7 apr 2015 kl. 17:21 skrev Erik Joelsson : > > (corrected subject) > >> On 2015-04-07 17:15, Erik Joelsson wrote: >> Hello, >> >> When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557 >> Patch inline: >> >> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk >> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100 >> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200 >> @@ -38,6 +38,11 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate >> +# a binary that is compatible with windows versions older than 7/2008R2. >> +# See MSDN documentation for GetProcessMemoryInfo for more information. >> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1 >> + >> BUILD_LIBMANAGEMENT_EXCLUDES := >> >> ifneq ($(OPENJDK_TARGET_OS), solaris) >> >> >> /Erik > From staffan.larsen at oracle.com Wed Apr 8 10:21:14 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Apr 2015 12:21:14 +0200 Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9 Message-ID: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> Please review these small changes to support an addition of closed code to the java.instrument module. webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Apr 8 10:32:07 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 08 Apr 2015 12:32:07 +0200 Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9 In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> Message-ID: <552503A7.9080901@oracle.com> Looks good to me. /Erik On 2015-04-08 12:21, Staffan Larsen wrote: > Please review these small changes to support an addition of closed code to the java.instrument module. > > webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ > > Thanks, > /Staffan From staffan.larsen at oracle.com Wed Apr 8 11:40:29 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 8 Apr 2015 13:40:29 +0200 Subject: RFR: 8075331 jdb eval java.util.Arrays.asList(array) shows inconsistent behaviour Message-ID: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com> Hi, When calling varargs methods from JDI, we end up in MethodImpl.handleVarArgs() which has some logic to figure out how to call the varargs method with the parameters given. It depends on InvokeableType.isAssignableTo() to do this. This patch fixes a bug in isAssignableTo() where the implementation would say that an interface type was not assignable to java.lang.Object. With that fix in place, the reproducer from the bug and the new test passes. Testing: all com/sun/jdi test and nsk.jdi.testlist on all platforms. bug: https://bugs.openjdk.java.net/browse/JDK-8075331 webrev: http://cr.openjdk.java.net/~sla/8075331/webrev.00/ Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Apr 8 12:25:18 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 08 Apr 2015 14:25:18 +0200 Subject: RFR: 8075331 jdb eval java.util.Arrays.asList(array) shows inconsistent behaviour In-Reply-To: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com> References: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com> Message-ID: <55251E2E.40605@oracle.com> Looks good! Just update the copyright year in InterfaceTypeImpl.java -JB- On 8.4.2015 13:40, Staffan Larsen wrote: > Hi, > > When calling varargs methods from JDI, we end up in > MethodImpl.handleVarArgs() which has some logic to figure out how to > call the varargs method with the parameters given. It depends on > InvokeableType.isAssignableTo() to do this. This patch fixes a bug in > isAssignableTo() where the implementation would say that an interface > type was not assignable to java.lang.Object. With that fix in place, the > reproducer from the bug and the new test passes. > > Testing: all com/sun/jdi test and nsk.jdi.testlist on all platforms. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075331 > webrev: http://cr.openjdk.java.net/~sla/8075331/webrev.00/ > > Thanks, > /Staffan From daniel.daugherty at oracle.com Wed Apr 8 13:54:26 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 08 Apr 2015 07:54:26 -0600 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55247FCB.6050000@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> Message-ID: <55253312.7040105@oracle.com> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: > On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >> >> >> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>> >>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it >>>> to find the method. >>>> >>>> But this is only going to find the method if it happens to be in >>>> the cpCache somewhere. I think >>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>>> 100% sure). In which case, you can look at that class to find the >>>> method with idnum. >>> I'm not 100% sure either. >>> Ok, I will check if using the prev_constant_pool()->pool_holder() is >>> going to work. >>> It'd make it more consistent with the jdk 9 fix. >> >> This is the updated webrev. > Sorry, forgot to paste the link: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ Comparing the two patch files looks good. A couple of nits: src/share/vm/classfile/javaClasses.cpp L1451: // Use specific ik version... L1884: // Use specific ik version... grammar: 'Use a specific ik version...' L1452: // refer to version that... L1885: // refer to version that... grammar: 'refer to a version that...' src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/oops/instanceKlass.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. Thumbs up. Dan > > Thanks, > Serguei > >> It is more consistent with the jdk 9 fix. >> Thank you for the suggestion! >> >> Thanks, >> Serguei >> >>> >>> Important part is that at least the saved cpref can be used to find >>> method name in the >>> the_class cpool if the attempt to find in the previous list cpCaches >>> was unsuccessful. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Coleen >>>> >>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen, >>>>> >>>>> Thank you for looking at this! >>>>> >>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>> >>>>> 8u60: >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>> + if (idnum >= methods()->length()) { >>>>> + return NULL; >>>>> + } >>>>> + Method* m = methods()->at(idnum); >>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + // Obsolete method idnum does not match the original idnum >>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>> + m = methods()->at(index); >>>>> + if (m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> + >>>>> + >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>> + if (constants()->version() == version) { >>>>> + return method_with_orig_idnum(idnum); >>>>> + } >>>>> + ConstantPoolCache* cp_cache = NULL; >>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>> + if (prev_cp->version() == version) { >>>>> + cp_cache = prev_cp->cache(); >>>>> + break; >>>>> + } >>>>> + } >>>>> + if (cp_cache == NULL) { >>>>> + return NULL; // The pv_node is gone, no method is found >>>>> + } >>>>> + Method* method = NULL; >>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>> + method = entry->get_interesting_method_entry(this); >>>>> + if (method == NULL) { >>>>> + continue; // skip uninteresting entries >>>>> + } >>>>> + if (method->orig_method_idnum() == idnum) { >>>>> + return method; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> >>>>> >>>>> jdk 9: >>>>> >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>> + if (idnum >= methods()->length()) { >>>>> + return NULL; >>>>> + } >>>>> + Method* m = methods()->at(idnum); >>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + // Obsolete method idnum does not match the original idnum >>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>> + m = methods()->at(index); >>>>> + if (m->orig_method_idnum() == idnum) { >>>>> + return m; >>>>> + } >>>>> + } >>>>> + // None found, return null for the caller to handle. >>>>> + return NULL; >>>>> +} >>>>> + >>>>> + >>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>> + InstanceKlass* holder = get_klass_version(version); >>>>> + if (holder == NULL) { >>>>> + return NULL; // The version of klass is gone, no method is found >>>>> + } >>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>> + return method; >>>>> +} >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>> >>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>> It seems mostly the same to me. >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen and Dan, >>>>>>> >>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>> >>>>>>> Please, let me know if you have any chance and plans to review >>>>>>> this. >>>>>>> Would it be enough to have just one (R) reviewer for a non-clean >>>>>>> backport? >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>> >>>>>>>> 8u60 hotspot webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>> >>>>>>>> >>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 9 hotspot webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>> >>>>>>>> >>>>>>>> 9 webrev for unit test update: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> The 9 fix can not be applied cleanly so that I have to rework >>>>>>>> the fix a little bit. >>>>>>>> >>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>> The issue is that the methods and related klass versions are >>>>>>>> not kept alive if a class redefinition >>>>>>>> takes place between catching a Throwable and taking a thread >>>>>>>> dump. >>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>> reconstruction of method name becomes impossible. >>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>> valid method name. >>>>>>>> >>>>>>>> The solution is to use current klass version and method >>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>> to find required method pointer. In the worst case when the >>>>>>>> related klass version is gone >>>>>>>> (was not included to or was removed from the >>>>>>>> previous_versions linked list), a saved method name >>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>> the method name. >>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>> stack frame. >>>>>>>> >>>>>>>> Testing in progress: >>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>> java/lang/instrument >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Apr 8 15:12:29 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 Apr 2015 08:12:29 -0700 Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9 In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> Message-ID: <5525455D.7000501@oracle.com> On 4/8/2015 3:21 AM, Staffan Larsen wrote: > Please review these small changes to support an addition of closed code to the java.instrument module. > > webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ The change looks fine. Mandy From serguei.spitsyn at oracle.com Wed Apr 8 18:38:21 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 08 Apr 2015 11:38:21 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55253312.7040105@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> Message-ID: <5525759D.8090506@oracle.com> Thanks, Dan! I will correct the grammar before the push.. Thanks, Serguei On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: > On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>> >>> >>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>> >>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>> it to find the method. >>>>> >>>>> But this is only going to find the method if it happens to be in >>>>> the cpCache somewhere. I think >>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not >>>>> 100% sure). In which case, you can look at that class to find the >>>>> method with idnum. >>>> I'm not 100% sure either. >>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>> is going to work. >>>> It'd make it more consistent with the jdk 9 fix. >>> >>> This is the updated webrev. >> Sorry, forgot to paste the link: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ > > Comparing the two patch files looks good. A couple of nits: > > src/share/vm/classfile/javaClasses.cpp > L1451: // Use specific ik version... > L1884: // Use specific ik version... > grammar: 'Use a specific ik version...' > > L1452: // refer to version that... > L1885: // refer to version that... > grammar: 'refer to a version that...' > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > Thumbs up. > > Dan > > >> >> Thanks, >> Serguei >> >>> It is more consistent with the jdk 9 fix. >>> Thank you for the suggestion! >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Important part is that at least the saved cpref can be used to find >>>> method name in the >>>> the_class cpool if the attempt to find in the previous list >>>> cpCaches was unsuccessful. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>> >>>>>> 8u60: >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>> + if (idnum >= methods()->length()) { >>>>>> + return NULL; >>>>>> + } >>>>>> + Method* m = methods()->at(idnum); >>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + // Obsolete method idnum does not match the original idnum >>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>> + m = methods()->at(index); >>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> + >>>>>> + >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>> + if (constants()->version() == version) { >>>>>> + return method_with_orig_idnum(idnum); >>>>>> + } >>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>> + if (prev_cp->version() == version) { >>>>>> + cp_cache = prev_cp->cache(); >>>>>> + break; >>>>>> + } >>>>>> + } >>>>>> + if (cp_cache == NULL) { >>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>> + } >>>>>> + Method* method = NULL; >>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>> + method = entry->get_interesting_method_entry(this); >>>>>> + if (method == NULL) { >>>>>> + continue; // skip uninteresting entries >>>>>> + } >>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>> + return method; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> >>>>>> >>>>>> jdk 9: >>>>>> >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>> + if (idnum >= methods()->length()) { >>>>>> + return NULL; >>>>>> + } >>>>>> + Method* m = methods()->at(idnum); >>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + // Obsolete method idnum does not match the original idnum >>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>> + m = methods()->at(index); >>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>> + return m; >>>>>> + } >>>>>> + } >>>>>> + // None found, return null for the caller to handle. >>>>>> + return NULL; >>>>>> +} >>>>>> + >>>>>> + >>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>> + if (holder == NULL) { >>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>> + } >>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>> + return method; >>>>>> +} >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>>> It seems mostly the same to me. >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen and Dan, >>>>>>>> >>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>> >>>>>>>> Please, let me know if you have any chance and plans to review >>>>>>>> this. >>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>> non-clean backport? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>> >>>>>>>>> 8u60 hotspot webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>> >>>>>>>>> >>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 9 hotspot webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> 9 webrev for unit test update: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>> rework the fix a little bit. >>>>>>>>> >>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>> The issue is that the methods and related klass versions are >>>>>>>>> not kept alive if a class redefinition >>>>>>>>> takes place between catching a Throwable and taking a thread >>>>>>>>> dump. >>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>>> valid method name. >>>>>>>>> >>>>>>>>> The solution is to use current klass version and method >>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>> to find required method pointer. In the worst case when the >>>>>>>>> related klass version is gone >>>>>>>>> (was not included to or was removed from the >>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>>> the method name. >>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>> stack frame. >>>>>>>>> >>>>>>>>> Testing in progress: >>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>> java/lang/instrument >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Apr 8 18:49:28 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 08 Apr 2015 14:49:28 -0400 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <5525759D.8090506@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> <5525759D.8090506@oracle.com> Message-ID: <55257838.8080605@oracle.com> Serguei, This latest version looks great. Coleen On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote: > Thanks, Dan! > > I will correct the grammar before the push.. > > Thanks, > Serguei > > On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: >> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> >>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>>> >>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>>> it to find the method. >>>>>> >>>>>> But this is only going to find the method if it happens to be in >>>>>> the cpCache somewhere. I think >>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class >>>>>> (not 100% sure). In which case, you can look at that class to >>>>>> find the method with idnum. >>>>> I'm not 100% sure either. >>>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>>> is going to work. >>>>> It'd make it more consistent with the jdk 9 fix. >>>> >>>> This is the updated webrev. >>> Sorry, forgot to paste the link: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ >> >> Comparing the two patch files looks good. A couple of nits: >> >> src/share/vm/classfile/javaClasses.cpp >> L1451: // Use specific ik version... >> L1884: // Use specific ik version... >> grammar: 'Use a specific ik version...' >> >> L1452: // refer to version that... >> L1885: // refer to version that... >> grammar: 'refer to a version that...' >> >> src/share/vm/classfile/javaClasses.hpp >> No comments. >> >> src/share/vm/oops/instanceKlass.cpp >> No comments. >> >> src/share/vm/oops/instanceKlass.hpp >> No comments. >> >> Thumbs up. >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>>> It is more consistent with the jdk 9 fix. >>>> Thank you for the suggestion! >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Important part is that at least the saved cpref can be used to >>>>> find method name in the >>>>> the_class cpool if the attempt to find in the previous list >>>>> cpCaches was unsuccessful. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Thank you for looking at this! >>>>>>> >>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>>> >>>>>>> 8u60: >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>> + if (idnum >= methods()->length()) { >>>>>>> + return NULL; >>>>>>> + } >>>>>>> + Method* m = methods()->at(idnum); >>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>> + m = methods()->at(index); >>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> + >>>>>>> + >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>> + if (constants()->version() == version) { >>>>>>> + return method_with_orig_idnum(idnum); >>>>>>> + } >>>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>>> + if (prev_cp->version() == version) { >>>>>>> + cp_cache = prev_cp->cache(); >>>>>>> + break; >>>>>>> + } >>>>>>> + } >>>>>>> + if (cp_cache == NULL) { >>>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>>> + } >>>>>>> + Method* method = NULL; >>>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>>> + method = entry->get_interesting_method_entry(this); >>>>>>> + if (method == NULL) { >>>>>>> + continue; // skip uninteresting entries >>>>>>> + } >>>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>>> + return method; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> >>>>>>> >>>>>>> jdk 9: >>>>>>> >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>> + if (idnum >= methods()->length()) { >>>>>>> + return NULL; >>>>>>> + } >>>>>>> + Method* m = methods()->at(idnum); >>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>> + m = methods()->at(index); >>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>> + return m; >>>>>>> + } >>>>>>> + } >>>>>>> + // None found, return null for the caller to handle. >>>>>>> + return NULL; >>>>>>> +} >>>>>>> + >>>>>>> + >>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>>> + if (holder == NULL) { >>>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>>> + } >>>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>>> + return method; >>>>>>> +} >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> This backport looks good. Why didn't the patch apply cleanly? >>>>>>>> It seems mostly the same to me. >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Coleen and Dan, >>>>>>>>> >>>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>>> >>>>>>>>> Please, let me know if you have any chance and plans to review >>>>>>>>> this. >>>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>>> non-clean backport? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>>> >>>>>>>>>> 8u60 hotspot webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9 hotspot webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9 webrev for unit test update: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>>> rework the fix a little bit. >>>>>>>>>> >>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>>> The issue is that the methods and related klass versions >>>>>>>>>> are not kept alive if a class redefinition >>>>>>>>>> takes place between catching a Throwable and taking a >>>>>>>>>> thread dump. >>>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>>> In such a case, the null reference is returned instead of a >>>>>>>>>> valid method name. >>>>>>>>>> >>>>>>>>>> The solution is to use current klass version and method >>>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>>> to find required method pointer. In the worst case when the >>>>>>>>>> related klass version is gone >>>>>>>>>> (was not included to or was removed from the >>>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>>> CP index of the latest klass version can be used to restore >>>>>>>>>> the method name. >>>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>>> stack frame. >>>>>>>>>> >>>>>>>>>> Testing in progress: >>>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>>> java/lang/instrument >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 8 18:58:07 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 08 Apr 2015 11:58:07 -0700 Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. In-Reply-To: <55257838.8080605@oracle.com> References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com> <55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com> <55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com> <5525759D.8090506@oracle.com> <55257838.8080605@oracle.com> Message-ID: <55257A3F.5020700@oracle.com> Thanks, Collen! It was a great suggestion. :) Thanks, Serguei On 4/8/15 11:49 AM, Coleen Phillimore wrote: > > Serguei, This latest version looks great. > Coleen > > On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote: >> Thanks, Dan! >> >> I will correct the grammar before the push.. >> >> Thanks, >> Serguei >> >> On 4/8/15 6:54 AM, Daniel D. Daugherty wrote: >>> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote: >>>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> >>>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using >>>>>>> it to find the method. >>>>>>> >>>>>>> But this is only going to find the method if it happens to be in >>>>>>> the cpCache somewhere. I think >>>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class >>>>>>> (not 100% sure). In which case, you can look at that class to >>>>>>> find the method with idnum. >>>>>> I'm not 100% sure either. >>>>>> Ok, I will check if using the prev_constant_pool()->pool_holder() >>>>>> is going to work. >>>>>> It'd make it more consistent with the jdk 9 fix. >>>>> >>>>> This is the updated webrev. >>>> Sorry, forgot to paste the link: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/ >>> >>> Comparing the two patch files looks good. A couple of nits: >>> >>> src/share/vm/classfile/javaClasses.cpp >>> L1451: // Use specific ik version... >>> L1884: // Use specific ik version... >>> grammar: 'Use a specific ik version...' >>> >>> L1452: // refer to version that... >>> L1885: // refer to version that... >>> grammar: 'refer to a version that...' >>> >>> src/share/vm/classfile/javaClasses.hpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> No comments. >>> >>> src/share/vm/oops/instanceKlass.hpp >>> No comments. >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> It is more consistent with the jdk 9 fix. >>>>> Thank you for the suggestion! >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Important part is that at least the saved cpref can be used to >>>>>> find method name in the >>>>>> the_class cpool if the attempt to find in the previous list >>>>>> cpCaches was unsuccessful. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Thank you for looking at this! >>>>>>>> >>>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp. >>>>>>>> >>>>>>>> 8u60: >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>>> + if (idnum >= methods()->length()) { >>>>>>>> + return NULL; >>>>>>>> + } >>>>>>>> + Method* m = methods()->at(idnum); >>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>>> + m = methods()->at(index); >>>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> + >>>>>>>> + >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>>> + if (constants()->version() == version) { >>>>>>>> + return method_with_orig_idnum(idnum); >>>>>>>> + } >>>>>>>> + ConstantPoolCache* cp_cache = NULL; >>>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this); >>>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version(); >>>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) { >>>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool(); >>>>>>>> + if (prev_cp->version() == version) { >>>>>>>> + cp_cache = prev_cp->cache(); >>>>>>>> + break; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + if (cp_cache == NULL) { >>>>>>>> + return NULL; // The pv_node is gone, no method is found >>>>>>>> + } >>>>>>>> + Method* method = NULL; >>>>>>>> + for (int i = 0; i < cp_cache->length(); i++) { >>>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i); >>>>>>>> + method = entry->get_interesting_method_entry(this); >>>>>>>> + if (method == NULL) { >>>>>>>> + continue; // skip uninteresting entries >>>>>>>> + } >>>>>>>> + if (method->orig_method_idnum() == idnum) { >>>>>>>> + return method; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> jdk 9: >>>>>>>> >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) { >>>>>>>> + if (idnum >= methods()->length()) { >>>>>>>> + return NULL; >>>>>>>> + } >>>>>>>> + Method* m = methods()->at(idnum); >>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + // Obsolete method idnum does not match the original idnum >>>>>>>> + for (int index = 0; index < methods()->length(); ++index) { >>>>>>>> + m = methods()->at(index); >>>>>>>> + if (m->orig_method_idnum() == idnum) { >>>>>>>> + return m; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // None found, return null for the caller to handle. >>>>>>>> + return NULL; >>>>>>>> +} >>>>>>>> + >>>>>>>> + >>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) { >>>>>>>> + InstanceKlass* holder = get_klass_version(version); >>>>>>>> + if (holder == NULL) { >>>>>>>> + return NULL; // The version of klass is gone, no method is found >>>>>>>> + } >>>>>>>> + Method* method = holder->method_with_orig_idnum(idnum); >>>>>>>> + return method; >>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> This backport looks good. Why didn't the patch apply >>>>>>>>> cleanly? It seems mostly the same to me. >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Coleen and Dan, >>>>>>>>>> >>>>>>>>>> I'm asking you as the jdk 9 reviewers... >>>>>>>>>> >>>>>>>>>> Please, let me know if you have any chance and plans to >>>>>>>>>> review this. >>>>>>>>>> Would it be enough to have just one (R) reviewer for a >>>>>>>>>> non-clean backport? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the jdk 8u60 backport for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662 >>>>>>>>>>> >>>>>>>>>>> 8u60 hotspot webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly): >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9 hotspot webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9 webrev for unit test update: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> The 9 fix can not be applied cleanly so that I have to >>>>>>>>>>> rework the fix a little bit. >>>>>>>>>>> >>>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU >>>>>>>>>>> profiling in NetBeans Profiler and VisualVM. >>>>>>>>>>> The issue is that the methods and related klass versions >>>>>>>>>>> are not kept alive if a class redefinition >>>>>>>>>>> takes place between catching a Throwable and taking a >>>>>>>>>>> thread dump. >>>>>>>>>>> It can result in loosing an obsolete method, and so, the >>>>>>>>>>> reconstruction of method name becomes impossible. >>>>>>>>>>> In such a case, the null reference is returned instead of >>>>>>>>>>> a valid method name. >>>>>>>>>>> >>>>>>>>>>> The solution is to use current klass version and method >>>>>>>>>>> orig_idnum instead of ordinary method idnum >>>>>>>>>>> to find required method pointer. In the worst case when >>>>>>>>>>> the related klass version is gone >>>>>>>>>>> (was not included to or was removed from the >>>>>>>>>>> previous_versions linked list), a saved method name >>>>>>>>>>> CP index of the latest klass version can be used to >>>>>>>>>>> restore the method name. >>>>>>>>>>> The footprint extra overhead for this approach is u2 per >>>>>>>>>>> stack frame. >>>>>>>>>>> >>>>>>>>>>> Testing in progress: >>>>>>>>>>> In progress: nsk redefine classes tests, JTREG >>>>>>>>>>> java/lang/instrument >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Apr 9 13:56:13 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 09 Apr 2015 15:56:13 +0200 Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9 In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com> Message-ID: <552684FD.2070100@oracle.com> On 2015-04-08 12:21, Staffan Larsen wrote: > Please review these small changes to support an addition of closed code to the java.instrument module. > > webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ Looks good to me. /Magnus From dmitry.samersoff at oracle.com Thu Apr 9 15:54:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 09 Apr 2015 18:54:52 +0300 Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda Message-ID: <5526A0CC.5010801@oracle.com> Everybody, Please, review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/ When dumping a heap, SA agent iterates over SystemDictionary first and store object information to internal cache. Lambda classes is not present in SystemDictionary so they don't cached. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Apr 9 16:12:22 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Apr 2015 18:12:22 +0200 Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda In-Reply-To: <5526A0CC.5010801@oracle.com> References: <5526A0CC.5010801@oracle.com> Message-ID: <5526A4E6.20004@oracle.com> Hi Dmitry, Indentation should be 4 spaces. Copyright year will need update. Otherwise looks good! -JB- On 9.4.2015 17:54, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/ > > When dumping a heap, SA agent iterates over SystemDictionary first and > store object information to internal cache. Lambda classes is not > present in SystemDictionary so they don't cached. > > > -Dmitry > From dmitry.samersoff at oracle.com Thu Apr 9 17:01:21 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 09 Apr 2015 20:01:21 +0300 Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda In-Reply-To: <5526A4E6.20004@oracle.com> References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com> Message-ID: <5526B061.1020306@oracle.com> Jaroslav, Thank you! Nits fixed in-place (press shift-reload) -Dmitry On 2015-04-09 19:12, Jaroslav Bachorik wrote: > Hi Dmitry, > > Indentation should be 4 spaces. > Copyright year will need update. > > Otherwise looks good! > > -JB- > > On 9.4.2015 17:54, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/ >> >> When dumping a heap, SA agent iterates over SystemDictionary first and >> store object information to internal cache. Lambda classes is not >> present in SystemDictionary so they don't cached. >> >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Apr 9 17:55:33 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Apr 2015 19:55:33 +0200 Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda In-Reply-To: <5526B061.1020306@oracle.com> References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com> <5526B061.1020306@oracle.com> Message-ID: <5526BD15.6010301@oracle.com> Thanks, good to go! -JB- On 9.4.2015 19:01, Dmitry Samersoff wrote: > Jaroslav, > > Thank you! > > Nits fixed in-place (press shift-reload) > > -Dmitry > > On 2015-04-09 19:12, Jaroslav Bachorik wrote: >> Hi Dmitry, >> >> Indentation should be 4 spaces. >> Copyright year will need update. >> >> Otherwise looks good! >> >> -JB- >> >> On 9.4.2015 17:54, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/ >>> >>> When dumping a heap, SA agent iterates over SystemDictionary first and >>> store object information to internal cache. Lambda classes is not >>> present in SystemDictionary so they don't cached. >>> >>> >>> -Dmitry >>> >> > > From jaroslav.bachorik at oracle.com Thu Apr 9 18:11:40 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Apr 2015 20:11:40 +0200 Subject: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE Message-ID: <5526C0DC.7000502@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 This fix is for an intermittent failure due to timing issues. The test is using an arbitrary waiting period to allow the tested thread to arrive to the requested state. Usually it works fine but under eg. heavy load this strategy will fail. The proposed solution is to explicitly check for the test thread arriving to the requested state instead of waiting eg. 10ms. I also took the liberty of removing the custom Semaphore implementation and replacing its usage with java.util.concurrent.Phaser Thanks, -JB- From jaroslav.bachorik at oracle.com Thu Apr 9 18:33:22 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Apr 2015 20:33:22 +0200 Subject: RFR 8076050: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java fails intermittently Message-ID: <5526C5F2.1010905@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8076050 Webrev: http://cr.openjdk.java.net/~jbachorik/8076050/webrev.00 This is another intermittently failing test due to timing problems. The test thread is requested to move to "TIMED_WAITING" state and the main thread then performs the asserts. The test thread will stay in "TIMED_WAITING" state 10s (lock.wait(10000) in test/java/lang/Thread/ThreadStateController.java#168) and after this timeout it moves on. The wait may be cancelled by the main thread after it has performed the asserts. This timeout might turn out insufficient. The proposed solution is to do `lock.wait(Integer.MAX_VALUE)` instead. Aside of this change I also introduced the usage of `Utils.adjustTimeout(timeout)` to adjust the requested timeouts to the test timeout scaling factor. The change in test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is purely for the purpose of improving the log output - currently, when the test fails the output is ignored; and this was fixed. Thanks, -JB- From staffan.larsen at oracle.com Thu Apr 9 18:54:20 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 9 Apr 2015 20:54:20 +0200 Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda In-Reply-To: <5526B061.1020306@oracle.com> References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com> <5526B061.1020306@oracle.com> Message-ID: <65F796FD-239E-451A-9F19-7D64D7F5C7FD@oracle.com> Looks good! Thanks, /Staffan > On 9 apr 2015, at 19:01, Dmitry Samersoff wrote: > > Jaroslav, > > Thank you! > > Nits fixed in-place (press shift-reload) > > -Dmitry > > On 2015-04-09 19:12, Jaroslav Bachorik wrote: >> Hi Dmitry, >> >> Indentation should be 4 spaces. >> Copyright year will need update. >> >> Otherwise looks good! >> >> -JB- >> >> On 9.4.2015 17:54, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/ >>> >>> When dumping a heap, SA agent iterates over SystemDictionary first and >>> store object information to internal cache. Lambda classes is not >>> present in SystemDictionary so they don't cached. >>> >>> >>> -Dmitry >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Apr 9 19:00:16 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 9 Apr 2015 21:00:16 +0200 Subject: RFR 8076050: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java fails intermittently In-Reply-To: <5526C5F2.1010905@oracle.com> References: <5526C5F2.1010905@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 9 apr 2015, at 20:33, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8076050 > Webrev: http://cr.openjdk.java.net/~jbachorik/8076050/webrev.00 > > This is another intermittently failing test due to timing problems. > > The test thread is requested to move to "TIMED_WAITING" state and the main thread then performs the asserts. The test thread will stay in "TIMED_WAITING" state 10s (lock.wait(10000) in test/java/lang/Thread/ThreadStateController.java#168) and after this timeout it moves on. The wait may be cancelled by the main thread after it has performed the asserts. > > This timeout might turn out insufficient. The proposed solution is to do `lock.wait(Integer.MAX_VALUE)` instead. Aside of this change I also introduced the usage of `Utils.adjustTimeout(timeout)` to adjust the requested timeouts to the test timeout scaling factor. > > The change in test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is purely for the purpose of improving the log output - currently, when the test fails the output is ignored; and this was fixed. > > > Thanks, > > -JB- From serguei.spitsyn at oracle.com Fri Apr 10 20:29:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Apr 2015 13:29:35 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <5514C2C1.9040302@oracle.com> References: <5514C2C1.9040302@oracle.com> Message-ID: <552832AF.8080204@oracle.com> Hi Coleen and Dan, This is the second class redefinition scalability/optimization fix that is in my queue to push into 9 and 8u60. The approach is similar to the first one but much smaller. For convenience, these are the links to the first scalability fix: Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Please, let me know if you have any chance to review this. This is the last one that is waiting for your attention! :) Thanks, Serguei On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8073705 > > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > > Summary: > > This is the 2-nd round of performance/calability fixes in class > redefinition. > This time, the two remaining issues that were left alone in the > first round fix: > - optimized ConstantPoolCache::adjust_method_entries() is used > for previous versions > - the MemberNameTable::adjust_method_entries() has been optimized > too > - some cleanup > > > Testing: > In progress: nsk redefine classes tests, JTREG java/lang/instrument, > com/sun/jdi > > > Thanks, > Serguei > From jaroslav.bachorik at oracle.com Mon Apr 13 08:07:06 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Apr 2015 10:07:06 +0200 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <5526C0DC.7000502@oracle.com> References: <5526C0DC.7000502@oracle.com> Message-ID: <552B792A.6000308@oracle.com> On 9.4.2015 20:11, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 > Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 > > This fix is for an intermittent failure due to timing issues. The test > is using an arbitrary waiting period to allow the tested thread to > arrive to the requested state. Usually it works fine but under eg. heavy > load this strategy will fail. The proposed solution is to explicitly > check for the test thread arriving to the requested state instead of > waiting eg. 10ms. > > I also took the liberty of removing the custom Semaphore implementation > and replacing its usage with java.util.concurrent.Phaser > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Apr 13 09:43:34 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Apr 2015 11:43:34 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory Message-ID: <552B8FC6.6030409@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 In situations when there are 10s of thousands ObjectNname instances around (enterprise setups etc.) the 3 separate internal boolean fields can lead to a noticeable memory waste. Adding insult to the injury, with the current field layout it is necessary to align the instances by 4 bytes. When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to inspect the object layout we can see this: Before optimization (JDK8u40): --- javax.management.ObjectName object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header)| N/A 12 4 int ObjectName._domain_length N/A 16 1 boolean ObjectName._domain_pattern N/A 17 1 boolean ObjectName._property_list_pattern N/A 18 1 boolean ObjectName._property_value_pattern N/A 19 1 (alignment/padding gap) N/A 20 4 String ObjectName._canonicalName N/A 24 4 Property[] ObjectName._kp_array N/A 28 4 Property[] ObjectName._ca_array N/A 32 4 Map ObjectName._propertyList N/A 36 4 (loss due to the next object alignment) Instance size: 40 bytes (estimated, the sample instance is not available) Space losses: 1 bytes internal + 4 bytes external = 5 bytes total {noformat} After optimization (JDK9 internal build): --- javax.management.ObjectName object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 2 short ObjectName._domain_length N/A 14 1 byte ObjectName._pattern_flag N/A 15 1 (alignment/padding gap) N/A 16 4 String ObjectName._canonicalName N/A 20 4 Property[] ObjectName._kp_array N/A 24 4 Property[] ObjectName._ca_array N/A 28 4 Map ObjectName._propertyList N/A Instance size: 32 bytes (estimated, the sample instance is not available) Space losses: 1 bytes internal + 0 bytes external = 1 bytes total After optimization we can save 8 bytes per instance which can translate to very interesting numbers on large installations. To achieve this the domain name length is set to be *short* instead of *int* and the three booleans kept for the performance purposes are encoded into one byte value (as proposed by the reporter, Jean-Francois Denise). All the regression and JCK tests are passing after this change. Thanks, -JB- From shanliang.jiang at oracle.com Mon Apr 13 09:45:15 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Mon, 13 Apr 2015 11:45:15 +0200 Subject: RFR: 8077408 javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails due to Port already in use: 2468 Message-ID: <552B902B.4010503@oracle.com> Hi, Please review this test fix. Instead to specify a port, we use "0" to get a free port. I also remove the test waiting time variable, better to reply on directly the test harness timeout. bug: https://bugs.openjdk.java.net/browse/JDK-8077408 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8077408/00/ Thanks, Shanliang From jaroslav.bachorik at oracle.com Mon Apr 13 09:49:06 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Apr 2015 11:49:06 +0200 Subject: RFR: 8077408 javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails due to Port already in use: 2468 In-Reply-To: <552B902B.4010503@oracle.com> References: <552B902B.4010503@oracle.com> Message-ID: <552B9112.7030801@oracle.com> Looks good! -JB- On 13.4.2015 11:45, Shanliang Jiang wrote: > Hi, > > Please review this test fix. > > Instead to specify a port, we use "0" to get a free port. > > I also remove the test waiting time variable, better to reply on > directly the test harness timeout. > > bug: https://bugs.openjdk.java.net/browse/JDK-8077408 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8077408/00/ > > > Thanks, > Shanliang From olivier.lagneau at oracle.com Mon Apr 13 12:09:28 2015 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 13 Apr 2015 14:09:28 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552B8FC6.6030409@oracle.com> References: <552B8FC6.6030409@oracle.com> Message-ID: <552BB1F8.1090103@oracle.com> Hi Jaroslav, Looks good to me. Nice to save 8 bytes on object name insatnces (~ 20%) ! Olivier Le 13/04/2015 11:43, Jaroslav Bachorik a ?crit : > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 > Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 > > In situations when there are 10s of thousands ObjectNname instances > around (enterprise setups etc.) the 3 separate internal boolean fields > can lead to a noticeable memory waste. Adding insult to the injury, > with the current field layout it is necessary to align the instances > by 4 bytes. > > When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to > inspect the object layout we can see this: > > Before optimization (JDK8u40): > --- > javax.management.ObjectName object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header)| N/A > 12 4 int ObjectName._domain_length N/A > 16 1 boolean ObjectName._domain_pattern N/A > 17 1 boolean ObjectName._property_list_pattern N/A > 18 1 boolean ObjectName._property_value_pattern N/A > 19 1 (alignment/padding gap) N/A > 20 4 String ObjectName._canonicalName N/A > 24 4 Property[] ObjectName._kp_array N/A > 28 4 Property[] ObjectName._ca_array N/A > 32 4 Map ObjectName._propertyList N/A > 36 4 (loss due to the next object alignment) > Instance size: 40 bytes (estimated, the sample instance is not available) > Space losses: 1 bytes internal + 4 bytes external = 5 bytes total > {noformat} > > After optimization (JDK9 internal build): > --- > > javax.management.ObjectName object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 2 short ObjectName._domain_length N/A > 14 1 byte ObjectName._pattern_flag N/A > 15 1 (alignment/padding gap) N/A > 16 4 String ObjectName._canonicalName N/A > 20 4 Property[] ObjectName._kp_array N/A > 24 4 Property[] ObjectName._ca_array N/A > 28 4 Map ObjectName._propertyList N/A > Instance size: 32 bytes (estimated, the sample instance is not available) > Space losses: 1 bytes internal + 0 bytes external = 1 bytes total > > > After optimization we can save 8 bytes per instance which can > translate to very interesting numbers on large installations. > > > To achieve this the domain name length is set to be *short* instead of > *int* and the three booleans kept for the performance purposes are > encoded into one byte value (as proposed by the reporter, > Jean-Francois Denise). > > All the regression and JCK tests are passing after this change. > > > Thanks, > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Apr 13 14:07:45 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 13 Apr 2015 10:07:45 -0400 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552B8FC6.6030409@oracle.com> References: <552B8FC6.6030409@oracle.com> Message-ID: <552BCDB1.704@Oracle.com> Hi Jaroslav, Minor comments: 1488+: In forms like: _pattern_flag &= (~PROPLIST_PATTERN & 0xff);" The &0xff seems unnecessary since the store is to a byte field. 1644: the ? and : operators should be surrounded by spaces. There are other style issues, such as then statements on the same line as the 'if' but that may be beyond the scope of this change. Otherwise looks fine (as a 9 reviewer, but not specifically a serviceability reviewer). Thanks, Roger On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 > Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 > > In situations when there are 10s of thousands ObjectNname instances > around (enterprise setups etc.) the 3 separate internal boolean fields > can lead to a noticeable memory waste. Adding insult to the injury, > with the current field layout it is necessary to align the instances > by 4 bytes. > > When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to > inspect the object layout we can see this: > > Before optimization (JDK8u40): > --- > javax.management.ObjectName object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header)| N/A > 12 4 int ObjectName._domain_length N/A > 16 1 boolean ObjectName._domain_pattern N/A > 17 1 boolean ObjectName._property_list_pattern N/A > 18 1 boolean ObjectName._property_value_pattern N/A > 19 1 (alignment/padding gap) N/A > 20 4 String ObjectName._canonicalName N/A > 24 4 Property[] ObjectName._kp_array N/A > 28 4 Property[] ObjectName._ca_array N/A > 32 4 Map ObjectName._propertyList N/A > 36 4 (loss due to the next object alignment) > Instance size: 40 bytes (estimated, the sample instance is not available) > Space losses: 1 bytes internal + 4 bytes external = 5 bytes total > {noformat} > > After optimization (JDK9 internal build): > --- > > javax.management.ObjectName object internals: > OFFSET SIZE TYPE DESCRIPTION VALUE > 0 12 (object header) N/A > 12 2 short ObjectName._domain_length N/A > 14 1 byte ObjectName._pattern_flag N/A > 15 1 (alignment/padding gap) N/A > 16 4 String ObjectName._canonicalName N/A > 20 4 Property[] ObjectName._kp_array N/A > 24 4 Property[] ObjectName._ca_array N/A > 28 4 Map ObjectName._propertyList N/A > Instance size: 32 bytes (estimated, the sample instance is not available) > Space losses: 1 bytes internal + 0 bytes external = 1 bytes total > > > After optimization we can save 8 bytes per instance which can > translate to very interesting numbers on large installations. > > > To achieve this the domain name length is set to be *short* instead of > *int* and the three booleans kept for the performance purposes are > encoded into one byte value (as proposed by the reporter, > Jean-Francois Denise). > > All the regression and JCK tests are passing after this change. > > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Apr 13 15:07:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Apr 2015 17:07:30 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552BCDB1.704@Oracle.com> References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com> Message-ID: <552BDBB2.1050503@oracle.com> Hi Roger, On 13.4.2015 16:07, Roger Riggs wrote: > Hi Jaroslav, > > Minor comments: > > 1488+: In forms like: > > _pattern_flag &= (~PROPLIST_PATTERN & 0xff);" > > The &0xff seems unnecessary since the store is to a byte field. Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01 > > 1644: the ? and : operators should be surrounded by spaces. > > There are other style issues, such as then statements on the same line > as the 'if' but that > may be beyond the scope of this change. I know but these style issue have been around since the file was first committed. I didn't address them because it didn't feel right to mix style changes with the actual functionality. Cheers, -JB- > > Otherwise looks fine (as a 9 reviewer, but not specifically a > serviceability reviewer). > > Thanks, Roger > > > On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 >> >> In situations when there are 10s of thousands ObjectNname instances >> around (enterprise setups etc.) the 3 separate internal boolean fields >> can lead to a noticeable memory waste. Adding insult to the injury, >> with the current field layout it is necessary to align the instances >> by 4 bytes. >> >> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to >> inspect the object layout we can see this: >> >> Before optimization (JDK8u40): >> --- >> javax.management.ObjectName object internals: >> OFFSET SIZE TYPE DESCRIPTION VALUE >> 0 12 (object header)| N/A >> 12 4 int ObjectName._domain_length N/A >> 16 1 boolean ObjectName._domain_pattern N/A >> 17 1 boolean ObjectName._property_list_pattern N/A >> 18 1 boolean ObjectName._property_value_pattern N/A >> 19 1 (alignment/padding gap) N/A >> 20 4 String ObjectName._canonicalName N/A >> 24 4 Property[] ObjectName._kp_array N/A >> 28 4 Property[] ObjectName._ca_array N/A >> 32 4 Map ObjectName._propertyList N/A >> 36 4 (loss due to the next object alignment) >> Instance size: 40 bytes (estimated, the sample instance is not available) >> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total >> {noformat} >> >> After optimization (JDK9 internal build): >> --- >> >> javax.management.ObjectName object internals: >> OFFSET SIZE TYPE DESCRIPTION VALUE >> 0 12 (object header) N/A >> 12 2 short ObjectName._domain_length N/A >> 14 1 byte ObjectName._pattern_flag N/A >> 15 1 (alignment/padding gap) N/A >> 16 4 String ObjectName._canonicalName N/A >> 20 4 Property[] ObjectName._kp_array N/A >> 24 4 Property[] ObjectName._ca_array N/A >> 28 4 Map ObjectName._propertyList N/A >> Instance size: 32 bytes (estimated, the sample instance is not available) >> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total >> >> >> After optimization we can save 8 bytes per instance which can >> translate to very interesting numbers on large installations. >> >> >> To achieve this the domain name length is set to be *short* instead of >> *int* and the three booleans kept for the performance purposes are >> encoded into one byte value (as proposed by the reporter, >> Jean-Francois Denise). >> >> All the regression and JCK tests are passing after this change. >> >> >> Thanks, >> >> -JB- > From serguei.spitsyn at oracle.com Tue Apr 14 03:42:39 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Apr 2015 20:42:39 -0700 Subject: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <5526C0DC.7000502@oracle.com> References: <5526C0DC.7000502@oracle.com> Message-ID: <552C8CAF.4080706@oracle.com> Jaroslav, Nice fix. I've checked all the synchronization/check points and they look correct. I hope, the test will be stable now! Thanks, Serguei On 4/9/15 11:11 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 > Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 > > This fix is for an intermittent failure due to timing issues. The test > is using an arbitrary waiting period to allow the tested thread to > arrive to the requested state. Usually it works fine but under eg. > heavy load this strategy will fail. The proposed solution is to > explicitly check for the test thread arriving to the requested state > instead of waiting eg. 10ms. > > I also took the liberty of removing the custom Semaphore > implementation and replacing its usage with java.util.concurrent.Phaser > > Thanks, > > -JB- From daniel.fuchs at oracle.com Tue Apr 14 07:38:03 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Apr 2015 09:38:03 +0200 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552B792A.6000308@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> Message-ID: <552CC3DB.80606@oracle.com> Hi Jaroslav, Shouldn't you also wait for the blockedThread to be blocked on lockA at around line 252? (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) best regards, -- daniel On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: > On 9.4.2015 20:11, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >> >> This fix is for an intermittent failure due to timing issues. The test >> is using an arbitrary waiting period to allow the tested thread to >> arrive to the requested state. Usually it works fine but under eg. heavy >> load this strategy will fail. The proposed solution is to explicitly >> check for the test thread arriving to the requested state instead of >> waiting eg. 10ms. >> >> I also took the liberty of removing the custom Semaphore implementation >> and replacing its usage with java.util.concurrent.Phaser >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Tue Apr 14 09:28:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Apr 2015 11:28:29 +0200 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552CC3DB.80606@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> <552CC3DB.80606@oracle.com> Message-ID: <552CDDBD.5010102@oracle.com> Hi Daniel, On 14.4.2015 09:38, Daniel Fuchs wrote: > Hi Jaroslav, > > Shouldn't you also wait for the blockedThread to be blocked on > lockA at around line 252? > (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) Yes, nice catch. Thanks! http://cr.openjdk.java.net/~jbachorik/8077327/webrev.01 -JB- > > best regards, > > -- daniel > > On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: >> On 9.4.2015 20:11, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >>> >>> This fix is for an intermittent failure due to timing issues. The test >>> is using an arbitrary waiting period to allow the tested thread to >>> arrive to the requested state. Usually it works fine but under eg. heavy >>> load this strategy will fail. The proposed solution is to explicitly >>> check for the test thread arriving to the requested state instead of >>> waiting eg. 10ms. >>> >>> I also took the liberty of removing the custom Semaphore implementation >>> and replacing its usage with java.util.concurrent.Phaser >>> >>> Thanks, >>> >>> -JB- >> > From yekaterina.kantserova at oracle.com Tue Apr 14 09:44:59 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Apr 2015 11:44:59 +0200 Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be unquarantined Message-ID: <552CE19B.4050903@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8077611 webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00 Thanks, Katja From daniel.fuchs at oracle.com Tue Apr 14 11:59:37 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Apr 2015 13:59:37 +0200 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552CDDBD.5010102@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> <552CC3DB.80606@oracle.com> <552CDDBD.5010102@oracle.com> Message-ID: <552D0129.1060506@oracle.com> On 14/04/15 11:28, Jaroslav Bachorik wrote: > Hi Daniel, > > On 14.4.2015 09:38, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> Shouldn't you also wait for the blockedThread to be blocked on >> lockA at around line 252? >> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) > > Yes, nice catch. Thanks! > > http://cr.openjdk.java.net/~jbachorik/8077327/webrev.01 Looks good! -- daniel > > -JB- > >> >> best regards, >> >> -- daniel >> >> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: >>> On 9.4.2015 20:11, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >>>> >>>> This fix is for an intermittent failure due to timing issues. The test >>>> is using an arbitrary waiting period to allow the tested thread to >>>> arrive to the requested state. Usually it works fine but under eg. >>>> heavy >>>> load this strategy will fail. The proposed solution is to explicitly >>>> check for the test thread arriving to the requested state instead of >>>> waiting eg. 10ms. >>>> >>>> I also took the liberty of removing the custom Semaphore implementation >>>> and replacing its usage with java.util.concurrent.Phaser >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From serguei.spitsyn at oracle.com Tue Apr 14 12:37:36 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Apr 2015 05:37:36 -0700 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552CC3DB.80606@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> <552CC3DB.80606@oracle.com> Message-ID: <552D0A10.4090605@oracle.com> On 4/14/15 12:38 AM, Daniel Fuchs wrote: > Hi Jaroslav, > > Shouldn't you also wait for the blockedThread to be blocked on > lockA at around line 252? > (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) I guess, it is about these lines: 255 Utils.checkThreadState(blockedThread, Thread.State.BLOCKED); 256 checkStack(blockedThread, blockedStack, bsDepth); The implementation of the Utils.checkThreadState() from Utils.java: public static void checkThreadState(Thread t, Thread.State expected) { waitForThreadState(t, expected); <=== It does the call to the waitForThreadState Thread.State state = tm.getThreadInfo(t.getId()).getThreadState(); if (state == null) { throw new RuntimeException(t.getName() + " expected to have " + expected + " but got null."); } if (state != expected) { t.dumpStack(); throw new RuntimeException(t.getName() + " expected to have " + expected + " but got " + state); } } Thanks, Serguei > > best regards, > > -- daniel > > On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: >> On 9.4.2015 20:11, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >>> >>> This fix is for an intermittent failure due to timing issues. The test >>> is using an arbitrary waiting period to allow the tested thread to >>> arrive to the requested state. Usually it works fine but under eg. >>> heavy >>> load this strategy will fail. The proposed solution is to explicitly >>> check for the test thread arriving to the requested state instead of >>> waiting eg. 10ms. >>> >>> I also took the liberty of removing the custom Semaphore implementation >>> and replacing its usage with java.util.concurrent.Phaser >>> >>> Thanks, >>> >>> -JB- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Apr 14 12:56:05 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Apr 2015 14:56:05 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552BDBB2.1050503@oracle.com> References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com> <552BDBB2.1050503@oracle.com> Message-ID: <552D0E65.1020805@oracle.com> Hi Jaroslav, I like this change, but it does introduce an incompatibility, so it probably needs a CCC and some release notes. For instance, this test passes with the current version of ObjectName: public class StringLengthTest { final static int smax = Short.MAX_VALUE; final static int smore = smax + 126; public static void main(String[] args) throws MalformedObjectNameException { char[] chars = new char[smore]; Arrays.fill(chars, 0, smax, 'a'); Arrays.fill(chars, smax, smore, 'b'); System.out.println(new ObjectName(new String(chars), "type", "Test")); } } I'm not sure what it will do with your changes :-) With that in mind I believe you should consider throwing InternalError - or IllegalArgumentException - instead of using 'assert' statements. BTW have you run the JCK? best regards, -- daniel On 13/04/15 17:07, Jaroslav Bachorik wrote: > Hi Roger, > > On 13.4.2015 16:07, Roger Riggs wrote: >> Hi Jaroslav, >> >> Minor comments: >> >> 1488+: In forms like: >> >> _pattern_flag &= (~PROPLIST_PATTERN & 0xff);" >> >> The &0xff seems unnecessary since the store is to a byte field. > > Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01 > >> >> 1644: the ? and : operators should be surrounded by spaces. >> >> There are other style issues, such as then statements on the same line >> as the 'if' but that >> may be beyond the scope of this change. > > I know but these style issue have been around since the file was first > committed. I didn't address them because it didn't feel right to mix > style changes with the actual functionality. > > Cheers, > > -JB- > >> >> Otherwise looks fine (as a 9 reviewer, but not specifically a >> serviceability reviewer). >> >> Thanks, Roger >> >> >> On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote: >>> Please, review the following change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 >>> >>> In situations when there are 10s of thousands ObjectNname instances >>> around (enterprise setups etc.) the 3 separate internal boolean fields >>> can lead to a noticeable memory waste. Adding insult to the injury, >>> with the current field layout it is necessary to align the instances >>> by 4 bytes. >>> >>> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to >>> inspect the object layout we can see this: >>> >>> Before optimization (JDK8u40): >>> --- >>> javax.management.ObjectName object internals: >>> OFFSET SIZE TYPE DESCRIPTION VALUE >>> 0 12 (object header)| N/A >>> 12 4 int ObjectName._domain_length N/A >>> 16 1 boolean ObjectName._domain_pattern N/A >>> 17 1 boolean ObjectName._property_list_pattern N/A >>> 18 1 boolean ObjectName._property_value_pattern N/A >>> 19 1 (alignment/padding gap) N/A >>> 20 4 String ObjectName._canonicalName N/A >>> 24 4 Property[] ObjectName._kp_array N/A >>> 28 4 Property[] ObjectName._ca_array N/A >>> 32 4 Map ObjectName._propertyList N/A >>> 36 4 (loss due to the next object alignment) >>> Instance size: 40 bytes (estimated, the sample instance is not >>> available) >>> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total >>> {noformat} >>> >>> After optimization (JDK9 internal build): >>> --- >>> >>> javax.management.ObjectName object internals: >>> OFFSET SIZE TYPE DESCRIPTION VALUE >>> 0 12 (object header) N/A >>> 12 2 short ObjectName._domain_length N/A >>> 14 1 byte ObjectName._pattern_flag N/A >>> 15 1 (alignment/padding gap) N/A >>> 16 4 String ObjectName._canonicalName N/A >>> 20 4 Property[] ObjectName._kp_array N/A >>> 24 4 Property[] ObjectName._ca_array N/A >>> 28 4 Map ObjectName._propertyList N/A >>> Instance size: 32 bytes (estimated, the sample instance is not >>> available) >>> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total >>> >>> >>> After optimization we can save 8 bytes per instance which can >>> translate to very interesting numbers on large installations. >>> >>> >>> To achieve this the domain name length is set to be *short* instead of >>> *int* and the three booleans kept for the performance purposes are >>> encoded into one byte value (as proposed by the reporter, >>> Jean-Francois Denise). >>> >>> All the regression and JCK tests are passing after this change. >>> >>> >>> Thanks, >>> >>> -JB- >> > From daniel.fuchs at oracle.com Tue Apr 14 12:58:42 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Apr 2015 14:58:42 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552D0E65.1020805@oracle.com> References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com> <552BDBB2.1050503@oracle.com> <552D0E65.1020805@oracle.com> Message-ID: <552D0F02.2020903@oracle.com> On 14/04/15 14:56, Daniel Fuchs wrote: > With that in mind I believe you should consider throwing > InternalError - or IllegalArgumentException - instead of > using 'assert' statements. Actually - MalformedObjectNameException would be more appropriate. Stupid me. -- daniel From jaroslav.bachorik at oracle.com Tue Apr 14 14:44:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Apr 2015 16:44:30 +0200 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552D0A10.4090605@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> <552CC3DB.80606@oracle.com> <552D0A10.4090605@oracle.com> Message-ID: <552D27CE.1080902@oracle.com> On 14.4.2015 14:37, serguei.spitsyn at oracle.com wrote: > On 4/14/15 12:38 AM, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> Shouldn't you also wait for the blockedThread to be blocked on >> lockA at around line 252? >> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) > I guess, it is about these lines: > > 255 Utils.checkThreadState(blockedThread, > Thread.State.BLOCKED); > 256 checkStack(blockedThread, blockedStack, bsDepth); > > The implementation of the Utils.checkThreadState() from Utils.java: > > public static void checkThreadState(Thread t, Thread.State expected) { > waitForThreadState(t, expected); <=== It does the call to the > waitForThreadState > > Thread.State state = tm.getThreadInfo(t.getId()).getThreadState(); > if (state == null) { > throw new RuntimeException(t.getName() + " expected to have " + > expected + " but got null."); > } > if (state != expected) { > t.dumpStack(); > throw new RuntimeException(t.getName() + > " expected to have " + expected + " but got " + state); > } > } Yes, that's true. On the other hand the original code did call "blockedThread.waitUntilBlocked()" explicitly - so I decided to keep the semantics to minimize the chance of any regressions. -JB- > > Thanks, > Serguei > > >> >> best regards, >> >> -- daniel >> >> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: >>> On 9.4.2015 20:11, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >>>> >>>> This fix is for an intermittent failure due to timing issues. The test >>>> is using an arbitrary waiting period to allow the tested thread to >>>> arrive to the requested state. Usually it works fine but under eg. >>>> heavy >>>> load this strategy will fail. The proposed solution is to explicitly >>>> check for the test thread arriving to the requested state instead of >>>> waiting eg. 10ms. >>>> >>>> I also took the liberty of removing the custom Semaphore implementation >>>> and replacing its usage with java.util.concurrent.Phaser >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Tue Apr 14 14:58:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Apr 2015 16:58:08 +0200 Subject: RFR 8041565: JMX ObjectName could be refactored to save memory In-Reply-To: <552D0E65.1020805@oracle.com> References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com> <552BDBB2.1050503@oracle.com> <552D0E65.1020805@oracle.com> Message-ID: <552D2B00.4090805@oracle.com> On 14.4.2015 14:56, Daniel Fuchs wrote: > Hi Jaroslav, > > I like this change, but it does introduce an incompatibility, > so it probably needs a CCC and some release notes. > > For instance, this test passes with the current version of > ObjectName: > > public class StringLengthTest { > > final static int smax = Short.MAX_VALUE; > final static int smore = smax + 126; > public static void main(String[] args) throws > MalformedObjectNameException { > char[] chars = new char[smore]; > Arrays.fill(chars, 0, smax, 'a'); > Arrays.fill(chars, smax, smore, 'b'); > > System.out.println(new ObjectName(new String(chars), "type", > "Test")); > } > > } > > I'm not sure what it will do with your changes :-) It will fail with assert (if enabled). Or truncate the domain name, I suppose. > > With that in mind I believe you should consider throwing > InternalError - or IllegalArgumentException - instead of > using 'assert' statements. This would probably be better. > > BTW have you run the JCK? Yes. All passed. I don't think JCK is testing for unrealistic values :) I don't see how one could come up with a domain name 32767 characters long. -JB- > > best regards, > > -- daniel > > On 13/04/15 17:07, Jaroslav Bachorik wrote: >> Hi Roger, >> >> On 13.4.2015 16:07, Roger Riggs wrote: >>> Hi Jaroslav, >>> >>> Minor comments: >>> >>> 1488+: In forms like: >>> >>> _pattern_flag &= (~PROPLIST_PATTERN & 0xff);" >>> >>> The &0xff seems unnecessary since the store is to a byte field. >> >> Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01 >> >>> >>> 1644: the ? and : operators should be surrounded by spaces. >>> >>> There are other style issues, such as then statements on the same line >>> as the 'if' but that >>> may be beyond the scope of this change. >> >> I know but these style issue have been around since the file was first >> committed. I didn't address them because it didn't feel right to mix >> style changes with the actual functionality. >> >> Cheers, >> >> -JB- >> >>> >>> Otherwise looks fine (as a 9 reviewer, but not specifically a >>> serviceability reviewer). >>> >>> Thanks, Roger >>> >>> >>> On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote: >>>> Please, review the following change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00 >>>> >>>> In situations when there are 10s of thousands ObjectNname instances >>>> around (enterprise setups etc.) the 3 separate internal boolean fields >>>> can lead to a noticeable memory waste. Adding insult to the injury, >>>> with the current field layout it is necessary to align the instances >>>> by 4 bytes. >>>> >>>> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to >>>> inspect the object layout we can see this: >>>> >>>> Before optimization (JDK8u40): >>>> --- >>>> javax.management.ObjectName object internals: >>>> OFFSET SIZE TYPE DESCRIPTION VALUE >>>> 0 12 (object header)| N/A >>>> 12 4 int ObjectName._domain_length N/A >>>> 16 1 boolean ObjectName._domain_pattern N/A >>>> 17 1 boolean ObjectName._property_list_pattern N/A >>>> 18 1 boolean ObjectName._property_value_pattern N/A >>>> 19 1 (alignment/padding gap) N/A >>>> 20 4 String ObjectName._canonicalName N/A >>>> 24 4 Property[] ObjectName._kp_array N/A >>>> 28 4 Property[] ObjectName._ca_array N/A >>>> 32 4 Map ObjectName._propertyList N/A >>>> 36 4 (loss due to the next object alignment) >>>> Instance size: 40 bytes (estimated, the sample instance is not >>>> available) >>>> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total >>>> {noformat} >>>> >>>> After optimization (JDK9 internal build): >>>> --- >>>> >>>> javax.management.ObjectName object internals: >>>> OFFSET SIZE TYPE DESCRIPTION VALUE >>>> 0 12 (object header) N/A >>>> 12 2 short ObjectName._domain_length N/A >>>> 14 1 byte ObjectName._pattern_flag N/A >>>> 15 1 (alignment/padding gap) N/A >>>> 16 4 String ObjectName._canonicalName N/A >>>> 20 4 Property[] ObjectName._kp_array N/A >>>> 24 4 Property[] ObjectName._ca_array N/A >>>> 28 4 Map ObjectName._propertyList N/A >>>> Instance size: 32 bytes (estimated, the sample instance is not >>>> available) >>>> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total >>>> >>>> >>>> After optimization we can save 8 bytes per instance which can >>>> translate to very interesting numbers on large installations. >>>> >>>> >>>> To achieve this the domain name length is set to be *short* instead of >>>> *int* and the three booleans kept for the performance purposes are >>>> encoded into one byte value (as proposed by the reporter, >>>> Jean-Francois Denise). >>>> >>>> All the regression and JCK tests are passing after this change. >>>> >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From serguei.spitsyn at oracle.com Tue Apr 14 20:06:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Apr 2015 13:06:35 -0700 Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE In-Reply-To: <552D27CE.1080902@oracle.com> References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com> <552CC3DB.80606@oracle.com> <552D0A10.4090605@oracle.com> <552D27CE.1080902@oracle.com> Message-ID: <552D734B.50802@oracle.com> On 4/14/15 7:44 AM, Jaroslav Bachorik wrote: > On 14.4.2015 14:37, serguei.spitsyn at oracle.com wrote: >> On 4/14/15 12:38 AM, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> Shouldn't you also wait for the blockedThread to be blocked on >>> lockA at around line 252? >>> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED)) >> I guess, it is about these lines: >> >> 255 Utils.checkThreadState(blockedThread, >> Thread.State.BLOCKED); >> 256 checkStack(blockedThread, blockedStack, >> bsDepth); >> >> The implementation of the Utils.checkThreadState() from Utils.java: >> >> public static void checkThreadState(Thread t, Thread.State >> expected) { >> waitForThreadState(t, expected); <=== It does the call to the >> waitForThreadState >> >> Thread.State state = >> tm.getThreadInfo(t.getId()).getThreadState(); >> if (state == null) { >> throw new RuntimeException(t.getName() + " expected to >> have " + >> expected + " but got null."); >> } >> if (state != expected) { >> t.dumpStack(); >> throw new RuntimeException(t.getName() + >> " expected to have " + expected + " but got " + >> state); >> } >> } > > Yes, that's true. On the other hand the original code did call > "blockedThread.waitUntilBlocked()" explicitly - so I decided to keep > the semantics to minimize the chance of any regressions. That's Ok. :) Thanks, Serguei > > -JB- > >> >> Thanks, >> Serguei >> >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote: >>>> On 9.4.2015 20:11, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00 >>>>> >>>>> This fix is for an intermittent failure due to timing issues. The >>>>> test >>>>> is using an arbitrary waiting period to allow the tested thread to >>>>> arrive to the requested state. Usually it works fine but under eg. >>>>> heavy >>>>> load this strategy will fail. The proposed solution is to explicitly >>>>> check for the test thread arriving to the requested state instead of >>>>> waiting eg. 10ms. >>>>> >>>>> I also took the liberty of removing the custom Semaphore >>>>> implementation >>>>> and replacing its usage with java.util.concurrent.Phaser >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From roland.westrelin at oracle.com Wed Apr 15 09:48:49 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 15 Apr 2015 11:48:49 +0200 Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken Message-ID: http://cr.openjdk.java.net/~roland/8077832/webrev.00/ I found 3 locations where the SA code is out of sync with the hotspot code. Roland. From staffan.larsen at oracle.com Wed Apr 15 11:03:14 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Apr 2015 13:03:14 +0200 Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be unquarantined In-Reply-To: <552CE19B.4050903@oracle.com> References: <552CE19B.4050903@oracle.com> Message-ID: <1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com> Looks good! Thanks, /Staffan > On 14 apr 2015, at 11:44, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8077611 > webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Apr 15 11:23:35 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Apr 2015 13:23:35 +0200 Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be unquarantined In-Reply-To: <1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com> References: <552CE19B.4050903@oracle.com> <1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com> Message-ID: <552E4A37.2050702@oracle.com> Staffan, thanks! On 04/15/2015 01:03 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 14 apr 2015, at 11:44, Yekaterina Kantserova wrote: >> >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8077611 >> webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00 >> >> Thanks, >> Katja From serguei.spitsyn at oracle.com Wed Apr 15 11:47:28 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2015 04:47:28 -0700 Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be unquarantined In-Reply-To: <552CE19B.4050903@oracle.com> References: <552CE19B.4050903@oracle.com> Message-ID: <552E4FD0.4080004@oracle.com> Look good. Thanks, Serguei On 4/14/15 2:44 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8077611 > webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00 > > Thanks, > Katja From dmitry.samersoff at oracle.com Wed Apr 15 14:24:11 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Apr 2015 17:24:11 +0300 Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken In-Reply-To: References: Message-ID: <552E748B.4090202@oracle.com> Roland, Looks good to me. -Dmitry On 2015-04-15 12:48, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8077832/webrev.00/ > > I found 3 locations where the SA code is out of sync with the hotspot code. > > Roland. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Apr 15 14:28:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Apr 2015 16:28:06 +0200 Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken In-Reply-To: References: Message-ID: <04E2ECF6-B209-48C8-8B8D-7B28FB1ABCEC@oracle.com> Looks good! Thanks, /Staffan > On 15 apr 2015, at 11:48, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8077832/webrev.00/ > > I found 3 locations where the SA code is out of sync with the hotspot code. > > Roland. From yekaterina.kantserova at oracle.com Wed Apr 15 14:46:18 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Apr 2015 16:46:18 +0200 Subject: RFR(XS): 8077423: jstatd is not terminated even though it cannot contact or bind to RMI Registry In-Reply-To: <5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com> References: <5527E38C.4090603@oracle.com> <5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com> Message-ID: <552E79BA.2050309@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8077423 webrev: http://cr.openjdk.java.net/~ykantser/8077423/webrev.00/ A couple of comments about changes in sun/tools/jstatd/JstatdTest.java. If the suggested fix will be accepted there will be no need of waitForJstatdRMI(), because jstad will either be started properly or will terminate. A check has been added that there is no RMi Registry already running on default port. Otherwise the test will fail fast. A sanity check for "-nr" option has been added as well. http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html "-nr Do not attempt to create an internal RMI registry within the jstatd process when an existing RMI registry is not found." Thanks, Katja From staffan.larsen at oracle.com Wed Apr 15 14:55:21 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Apr 2015 16:55:21 +0200 Subject: RFR(XS): 8077423: jstatd is not terminated even though it cannot contact or bind to RMI Registry In-Reply-To: <552E79BA.2050309@oracle.com> References: <5527E38C.4090603@oracle.com> <5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com> <552E79BA.2050309@oracle.com> Message-ID: <87312687-D97E-4306-880B-CD395D565064@oracle.com> Looks good! Thanks, /Staffan > On 15 apr 2015, at 16:46, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8077423 > webrev: http://cr.openjdk.java.net/~ykantser/8077423/webrev.00/ > > A couple of comments about changes in sun/tools/jstatd/JstatdTest.java. If the suggested fix will be accepted there will be no need of waitForJstatdRMI(), because jstad will either be started properly or will terminate. > > A check has been added that there is no RMi Registry already running on default port. Otherwise the test will fail fast. > > A sanity check for "-nr" option has been added as well. > > http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html > "-nr > Do not attempt to create an internal RMI registry within the jstatd process when an existing RMI registry is not found." > > > Thanks, > Katja From vladimir.kozlov at oracle.com Wed Apr 15 17:24:01 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Apr 2015 10:24:01 -0700 Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken In-Reply-To: References: Message-ID: <552E9EB1.6070607@oracle.com> Looks good. Thanks, Vladimir On 4/15/15 2:48 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8077832/webrev.00/ > > I found 3 locations where the SA code is out of sync with the hotspot code. > > Roland. > From joe.darcy at oracle.com Thu Apr 16 02:47:09 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 15 Apr 2015 19:47:09 -0700 Subject: JDK 9 RFR of JDK-8077923: Add missing doclint in javax.management Message-ID: <552F22AD.4030104@oracle.com> Hello, While trying to turn on doclint checking in the build on more modules, it came to my attention that various parts of the javax.management package are missing javadoc. Please review the straightforward changes to add the missing javadoc: JDK-8077923: Add missing doclint in javax.management http://cr.openjdk.java.net/~darcy/8077923.0/ Patch below. Once this issue is resolved, I'll do the follow-up work necessary to enable doclint checking on the java.management module. Thanks, -Joe --- old/src/java.management/share/classes/javax/management/AttributeValueExp.java 2015-04-15 19:40:40.296525183 -0700 +++ new/src/java.management/share/classes/javax/management/AttributeValueExp.java 2015-04-15 19:40:40.116615181 -0700 @@ -93,11 +93,10 @@ * * @return The ValueExp. * - * @exception BadAttributeValueExpException - * @exception InvalidApplicationException - * @exception BadStringOperationException - * @exception BadBinaryOpValueExpException - * + * @throws BadStringOperationException {@inheritDoc} + * @throws BadBinaryOpValueExpException {@inheritDoc} + * @throws BadAttributeValueExpException {@inheritDoc} + * @throws InvalidApplicationException {@inheritDoc} */ @Override public ValueExp apply(ObjectName name) throws BadStringOperationException, BadBinaryOpValueExpException, --- old/src/java.management/share/classes/javax/management/DescriptorKey.java 2015-04-15 19:40:40.740303194 -0700 +++ new/src/java.management/share/classes/javax/management/DescriptorKey.java 2015-04-15 19:40:40.564391190 -0700 @@ -168,5 +168,9 @@ @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface DescriptorKey { + /** + * Returns the descriptor key. + * @return the descriptor key + */ String value(); } --- old/src/java.management/share/classes/javax/management/DynamicMBean.java 2015-04-15 19:40:41.196075205 -0700 +++ new/src/java.management/share/classes/javax/management/DynamicMBean.java 2015-04-15 19:40:41.016165202 -0700 @@ -43,7 +43,7 @@ * * @return The value of the attribute retrieved. * - * @exception AttributeNotFoundException + * @exception AttributeNotFoundException if specified attribute does not exist or cannot be retrieved * @exception MBeanException Wraps a java.lang.Exception thrown by the MBean's getter. * @exception ReflectionException Wraps a java.lang.Exception thrown while trying to invoke the getter. * @@ -58,8 +58,8 @@ * @param attribute The identification of the attribute to * be set and the value it is to be set to. * - * @exception AttributeNotFoundException - * @exception InvalidAttributeValueException + * @exception AttributeNotFoundException if specified attribute does not exist or cannot be retrieved + * @exception InvalidAttributeValueException if value specified is not valid for the attribute * @exception MBeanException Wraps a java.lang.Exception thrown by the MBean's setter. * @exception ReflectionException Wraps a java.lang.Exception thrown while trying to invoke the MBean's setter. * --- old/src/java.management/share/classes/javax/management/ImmutableDescriptor.java 2015-04-15 19:40:41.639853215 -0700 +++ new/src/java.management/share/classes/javax/management/ImmutableDescriptor.java 2015-04-15 19:40:41.455945211 -0700 @@ -65,6 +65,8 @@ /** * Construct a descriptor containing the given fields and values. * + * @param fieldNames the field names + * @param fieldValues the field values * @throws IllegalArgumentException if either array is null, or * if the arrays have different sizes, or * if a field name is null or empty, or if the same field name @@ -81,6 +83,7 @@ * is {@code a=b=c} then the field name is {@code a} and its value * is {@code b=c}. * + * @param fields the field names * @throws IllegalArgumentException if the parameter is null, or * if a field name is empty, or if the same field name appears * more than once, or if one of the strings does not contain @@ -94,6 +97,7 @@ *

Construct a descriptor where the names and values of the fields * are the keys and values of the given Map.

* + * @param fields the field names and values * @throws IllegalArgumentException if the parameter is null, or * if a field name is null or empty, or if the same field name appears * more than once (which can happen because field names are not case --- old/src/java.management/share/classes/javax/management/QueryExp.java 2015-04-15 19:40:42.099623225 -0700 +++ new/src/java.management/share/classes/javax/management/QueryExp.java 2015-04-15 19:40:41.919713221 -0700 @@ -53,10 +53,13 @@ * * @return True if the query was successfully applied to the MBean, false otherwise * - * @exception BadStringOperationException - * @exception BadBinaryOpValueExpException - * @exception BadAttributeValueExpException - * @exception InvalidApplicationException + * @throws BadStringOperationException when an invalid string + * operation is passed to a method for constructing a query + * @throws BadBinaryOpValueExpException when an invalid expression + * is passed to a method for constructing a query + * @throws BadAttributeValueExpException when an invalid MBean + * attribute is passed to a query constructing method + * @throws InvalidApplicationException when an invalid apply is attempted */ public boolean apply(ObjectName name) throws BadStringOperationException, BadBinaryOpValueExpException, BadAttributeValueExpException, InvalidApplicationException ; --- old/src/java.management/share/classes/javax/management/StandardEmitterMBean.java 2015-04-15 19:40:42.559393236 -0700 +++ new/src/java.management/share/classes/javax/management/StandardEmitterMBean.java 2015-04-15 19:40:42.367489231 -0700 @@ -91,6 +91,7 @@ * that will have no effect on this object's * {@code getNotificationInfo()}.

* + * @param the implementation type of the MBean * @param implementation the implementation of the MBean interface. * @param mbeanInterface a Standard MBean interface. * @param emitter the object that will handle notifications. @@ -129,6 +130,7 @@ * that will have no effect on this object's * {@code getNotificationInfo()}.

* + * @param the implementation type of the MBean * @param implementation the implementation of the MBean interface. * @param mbeanInterface a Standard MBean interface. * @param isMXBean If true, the {@code mbeanInterface} parameter --- old/src/java.management/share/classes/javax/management/StringValueExp.java 2015-04-15 19:40:43.015165247 -0700 +++ new/src/java.management/share/classes/javax/management/StringValueExp.java 2015-04-15 19:40:42.839253243 -0700 @@ -95,11 +95,12 @@ * * @return The ValueExp. * - * @exception BadStringOperationException - * @exception BadBinaryOpValueExpException - * @exception BadAttributeValueExpException - * @exception InvalidApplicationException + * @throws BadStringOperationException {@inheritDoc} + * @throws BadBinaryOpValueExpException {@inheritDoc} + * @throws BadAttributeValueExpException {@inheritDoc} + * @throws InvalidApplicationException {@inheritDoc} */ + @Override public ValueExp apply(ObjectName name) throws BadStringOperationException, BadBinaryOpValueExpException, BadAttributeValueExpException, InvalidApplicationException { return this; --- old/src/java.management/share/classes/javax/management/ValueExp.java 2015-04-15 19:40:43.466939257 -0700 +++ new/src/java.management/share/classes/javax/management/ValueExp.java 2015-04-15 19:40:43.283031253 -0700 @@ -80,10 +80,13 @@ * * @return The ValueExp. * - * @exception BadStringOperationException - * @exception BadBinaryOpValueExpException - * @exception BadAttributeValueExpException - * @exception InvalidApplicationException + * @throws BadStringOperationException when an invalid string + * operation is passed to a method for constructing a query + * @throws BadBinaryOpValueExpException when an invalid expression + * is passed to a method for constructing a query + * @throws BadAttributeValueExpException when an invalid MBean + * attribute is passed to a query constructing method + * @throws InvalidApplicationException when an invalid apply is attempted */ public ValueExp apply(ObjectName name) throws BadStringOperationException, BadBinaryOpValueExpException, --- old/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java 2015-04-15 19:40:43.930707268 -0700 +++ new/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java 2015-04-15 19:40:43.746799263 -0700 @@ -307,6 +307,7 @@ /** * Creates and returns a copy of this object. + * @return a copy of this object */ public java.lang.Object clone(); --- old/src/java.management/share/classes/javax/management/monitor/Monitor.java 2015-04-15 19:40:44.386479279 -0700 +++ new/src/java.management/share/classes/javax/management/monitor/Monitor.java 2015-04-15 19:40:44.198573274 -0700 @@ -387,7 +387,7 @@ * * @return The name of the monitor MBean registered. * - * @exception Exception + * @exception Exception if something goes wrong */ public ObjectName preRegister(MBeanServer server, ObjectName name) throws Exception { @@ -416,7 +416,7 @@ *

* Stops the monitor. * - * @exception Exception + * @exception Exception if something goes wrong */ public void preDeregister() throws Exception { --- old/src/java.management/share/classes/javax/management/openmbean/ArrayType.java 2015-04-15 19:40:44.902221290 -0700 +++ new/src/java.management/share/classes/javax/management/openmbean/ArrayType.java 2015-04-15 19:40:44.670337285 -0700 @@ -793,6 +793,7 @@ * array type description = 3-dimension array of java.lang.String * } * + * @param the Java type that described instances must have * @param elementType the open type of element values contained * in the arrays described by this ArrayType * instance; must be an instance of either @@ -800,7 +801,7 @@ * TabularType or another ArrayType * with a SimpleType, CompositeType * or TabularType as its elementType. - * + * @return an {@code ArrayType} instance * @throws OpenDataException if elementType's className is not * one of the allowed Java class names for open * data. @@ -834,12 +835,14 @@ * array type description = 3-dimension array of int * } * + * @param the Java type that described instances must have * @param arrayClass a primitive array class such as {@code int[].class}, * {@code boolean[][].class}, etc. The {@link * #getElementOpenType()} method of the returned * {@code ArrayType} returns the {@link SimpleType} * corresponding to the wrapper type of the primitive * type of the array. + * @return an {@code ArrayType} instance * * @throws IllegalArgumentException if arrayClass is not * a primitive array. --- old/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15 19:40:45.397973302 -0700 +++ new/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15 19:40:45.218063297 -0700 @@ -195,7 +195,7 @@ * * @return The name of the timer MBean registered. * - * @exception java.lang.Exception + * @exception java.lang.Exception if something goes wrong */ public ObjectName preRegister(MBeanServer server, ObjectName name) throws java.lang.Exception { @@ -217,7 +217,7 @@ *

* Stops the timer. * - * @exception java.lang.Exception + * @exception java.lang.Exception if something goes wrong */ public void preDeregister() throws java.lang.Exception { From daniel.fuchs at oracle.com Thu Apr 16 07:10:52 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 Apr 2015 09:10:52 +0200 Subject: JDK 9 RFR of JDK-8077923: Add missing doclint in javax.management In-Reply-To: <552F22AD.4030104@oracle.com> References: <552F22AD.4030104@oracle.com> Message-ID: <552F607C.5080404@oracle.com> Hi Joe, Looks good to me! +1 for doclint :-) best regards, -- daniel On 4/16/15 4:47 AM, joe darcy wrote: > Hello, > > While trying to turn on doclint checking in the build on more modules, > it came to my attention that various parts of the javax.management > package are missing javadoc. Please review the straightforward changes > to add the missing javadoc: > > JDK-8077923: Add missing doclint in javax.management > http://cr.openjdk.java.net/~darcy/8077923.0/ > > Patch below. > > Once this issue is resolved, I'll do the follow-up work necessary to > enable doclint checking on the java.management module. > > Thanks, > > -Joe > > --- > old/src/java.management/share/classes/javax/management/AttributeValueExp.java > 2015-04-15 19:40:40.296525183 -0700 > +++ > new/src/java.management/share/classes/javax/management/AttributeValueExp.java > 2015-04-15 19:40:40.116615181 -0700 > @@ -93,11 +93,10 @@ > * > * @return The ValueExp. > * > - * @exception BadAttributeValueExpException > - * @exception InvalidApplicationException > - * @exception BadStringOperationException > - * @exception BadBinaryOpValueExpException > - * > + * @throws BadStringOperationException {@inheritDoc} > + * @throws BadBinaryOpValueExpException {@inheritDoc} > + * @throws BadAttributeValueExpException {@inheritDoc} > + * @throws InvalidApplicationException {@inheritDoc} > */ > @Override > public ValueExp apply(ObjectName name) throws > BadStringOperationException, BadBinaryOpValueExpException, > --- > old/src/java.management/share/classes/javax/management/DescriptorKey.java > 2015-04-15 19:40:40.740303194 -0700 > +++ > new/src/java.management/share/classes/javax/management/DescriptorKey.java > 2015-04-15 19:40:40.564391190 -0700 > @@ -168,5 +168,9 @@ > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > public @interface DescriptorKey { > + /** > + * Returns the descriptor key. > + * @return the descriptor key > + */ > String value(); > } > --- > old/src/java.management/share/classes/javax/management/DynamicMBean.java > 2015-04-15 19:40:41.196075205 -0700 > +++ > new/src/java.management/share/classes/javax/management/DynamicMBean.java > 2015-04-15 19:40:41.016165202 -0700 > @@ -43,7 +43,7 @@ > * > * @return The value of the attribute retrieved. > * > - * @exception AttributeNotFoundException > + * @exception AttributeNotFoundException if specified attribute > does not exist or cannot be retrieved > * @exception MBeanException Wraps a > java.lang.Exception thrown by the MBean's getter. > * @exception ReflectionException Wraps a > java.lang.Exception thrown while trying to invoke the > getter. > * > @@ -58,8 +58,8 @@ > * @param attribute The identification of the attribute to > * be set and the value it is to be set to. > * > - * @exception AttributeNotFoundException > - * @exception InvalidAttributeValueException > + * @exception AttributeNotFoundException if specified attribute > does not exist or cannot be retrieved > + * @exception InvalidAttributeValueException if value specified > is not valid for the attribute > * @exception MBeanException Wraps a > java.lang.Exception thrown by the MBean's setter. > * @exception ReflectionException Wraps a > java.lang.Exception thrown while trying to invoke the > MBean's setter. > * > --- > old/src/java.management/share/classes/javax/management/ImmutableDescriptor.java > 2015-04-15 19:40:41.639853215 -0700 > +++ > new/src/java.management/share/classes/javax/management/ImmutableDescriptor.java > 2015-04-15 19:40:41.455945211 -0700 > @@ -65,6 +65,8 @@ > /** > * Construct a descriptor containing the given fields and values. > * > + * @param fieldNames the field names > + * @param fieldValues the field values > * @throws IllegalArgumentException if either array is null, or > * if the arrays have different sizes, or > * if a field name is null or empty, or if the same field name > @@ -81,6 +83,7 @@ > * is {@code a=b=c} then the field name is {@code a} and its value > * is {@code b=c}. > * > + * @param fields the field names > * @throws IllegalArgumentException if the parameter is null, or > * if a field name is empty, or if the same field name appears > * more than once, or if one of the strings does not contain > @@ -94,6 +97,7 @@ > *

Construct a descriptor where the names and values of the > fields > * are the keys and values of the given Map.

> * > + * @param fields the field names and values > * @throws IllegalArgumentException if the parameter is null, or > * if a field name is null or empty, or if the same field name > appears > * more than once (which can happen because field names are not case > --- > old/src/java.management/share/classes/javax/management/QueryExp.java > 2015-04-15 19:40:42.099623225 -0700 > +++ > new/src/java.management/share/classes/javax/management/QueryExp.java > 2015-04-15 19:40:41.919713221 -0700 > @@ -53,10 +53,13 @@ > * > * @return True if the query was successfully applied to the > MBean, false otherwise > * > - * @exception BadStringOperationException > - * @exception BadBinaryOpValueExpException > - * @exception BadAttributeValueExpException > - * @exception InvalidApplicationException > + * @throws BadStringOperationException when an invalid string > + * operation is passed to a method for constructing a query > + * @throws BadBinaryOpValueExpException when an invalid expression > + * is passed to a method for constructing a query > + * @throws BadAttributeValueExpException when an invalid MBean > + * attribute is passed to a query constructing method > + * @throws InvalidApplicationException when an invalid apply is > attempted > */ > public boolean apply(ObjectName name) throws > BadStringOperationException, BadBinaryOpValueExpException, > BadAttributeValueExpException, InvalidApplicationException ; > --- > old/src/java.management/share/classes/javax/management/StandardEmitterMBean.java > 2015-04-15 19:40:42.559393236 -0700 > +++ > new/src/java.management/share/classes/javax/management/StandardEmitterMBean.java > 2015-04-15 19:40:42.367489231 -0700 > @@ -91,6 +91,7 @@ > * that will have no effect on this object's > * {@code getNotificationInfo()}.

> * > + * @param the implementation type of the MBean > * @param implementation the implementation of the MBean interface. > * @param mbeanInterface a Standard MBean interface. > * @param emitter the object that will handle notifications. > @@ -129,6 +130,7 @@ > * that will have no effect on this object's > * {@code getNotificationInfo()}.

> * > + * @param the implementation type of the MBean > * @param implementation the implementation of the MBean interface. > * @param mbeanInterface a Standard MBean interface. > * @param isMXBean If true, the {@code mbeanInterface} parameter > --- > old/src/java.management/share/classes/javax/management/StringValueExp.java > 2015-04-15 19:40:43.015165247 -0700 > +++ > new/src/java.management/share/classes/javax/management/StringValueExp.java > 2015-04-15 19:40:42.839253243 -0700 > @@ -95,11 +95,12 @@ > * > * @return The ValueExp. > * > - * @exception BadStringOperationException > - * @exception BadBinaryOpValueExpException > - * @exception BadAttributeValueExpException > - * @exception InvalidApplicationException > + * @throws BadStringOperationException {@inheritDoc} > + * @throws BadBinaryOpValueExpException {@inheritDoc} > + * @throws BadAttributeValueExpException {@inheritDoc} > + * @throws InvalidApplicationException {@inheritDoc} > */ > + @Override > public ValueExp apply(ObjectName name) throws > BadStringOperationException, BadBinaryOpValueExpException, > BadAttributeValueExpException, InvalidApplicationException { > return this; > --- > old/src/java.management/share/classes/javax/management/ValueExp.java > 2015-04-15 19:40:43.466939257 -0700 > +++ > new/src/java.management/share/classes/javax/management/ValueExp.java > 2015-04-15 19:40:43.283031253 -0700 > @@ -80,10 +80,13 @@ > * > * @return The ValueExp. > * > - * @exception BadStringOperationException > - * @exception BadBinaryOpValueExpException > - * @exception BadAttributeValueExpException > - * @exception InvalidApplicationException > + * @throws BadStringOperationException when an invalid string > + * operation is passed to a method for constructing a query > + * @throws BadBinaryOpValueExpException when an invalid expression > + * is passed to a method for constructing a query > + * @throws BadAttributeValueExpException when an invalid MBean > + * attribute is passed to a query constructing method > + * @throws InvalidApplicationException when an invalid apply is > attempted > */ > public ValueExp apply(ObjectName name) > throws BadStringOperationException, > BadBinaryOpValueExpException, > --- > old/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java > 2015-04-15 19:40:43.930707268 -0700 > +++ > new/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java > 2015-04-15 19:40:43.746799263 -0700 > @@ -307,6 +307,7 @@ > > /** > * Creates and returns a copy of this object. > + * @return a copy of this object > */ > public java.lang.Object clone(); > > --- > old/src/java.management/share/classes/javax/management/monitor/Monitor.java > 2015-04-15 19:40:44.386479279 -0700 > +++ > new/src/java.management/share/classes/javax/management/monitor/Monitor.java > 2015-04-15 19:40:44.198573274 -0700 > @@ -387,7 +387,7 @@ > * > * @return The name of the monitor MBean registered. > * > - * @exception Exception > + * @exception Exception if something goes wrong > */ > public ObjectName preRegister(MBeanServer server, ObjectName name) > throws Exception { > @@ -416,7 +416,7 @@ > *

> * Stops the monitor. > * > - * @exception Exception > + * @exception Exception if something goes wrong > */ > public void preDeregister() throws Exception { > > --- > old/src/java.management/share/classes/javax/management/openmbean/ArrayType.java > 2015-04-15 19:40:44.902221290 -0700 > +++ > new/src/java.management/share/classes/javax/management/openmbean/ArrayType.java > 2015-04-15 19:40:44.670337285 -0700 > @@ -793,6 +793,7 @@ > * array type description = 3-dimension array of java.lang.String > * } > * > + * @param the Java type that described instances must have > * @param elementType the open type of element values > contained > * in the arrays described by this > ArrayType > * instance; must be an instance of either > @@ -800,7 +801,7 @@ > * TabularType or another > ArrayType > * with a SimpleType, > CompositeType > * or TabularType as its > elementType. > - * > + * @return an {@code ArrayType} instance > * @throws OpenDataException if elementType's > className is not > * one of the allowed Java class names > for open > * data. > @@ -834,12 +835,14 @@ > * array type description = 3-dimension array of int > * } > * > + * @param the Java type that described instances must have > * @param arrayClass a primitive array class such as {@code > int[].class}, > * {@code boolean[][].class}, etc. The {@link > * #getElementOpenType()} method of the returned > * {@code ArrayType} returns the {@link > SimpleType} > * corresponding to the wrapper type of the > primitive > * type of the array. > + * @return an {@code ArrayType} instance > * > * @throws IllegalArgumentException if arrayClass is not > * a primitive array. > --- > old/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15 > 19:40:45.397973302 -0700 > +++ > new/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15 > 19:40:45.218063297 -0700 > @@ -195,7 +195,7 @@ > * > * @return The name of the timer MBean registered. > * > - * @exception java.lang.Exception > + * @exception java.lang.Exception if something goes wrong > */ > public ObjectName preRegister(MBeanServer server, ObjectName name) > throws java.lang.Exception { > @@ -217,7 +217,7 @@ > *

> * Stops the timer. > * > - * @exception java.lang.Exception > + * @exception java.lang.Exception if something goes wrong > */ > public void preDeregister() throws java.lang.Exception { > > From dmitry.samersoff at oracle.com Thu Apr 16 15:59:55 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Apr 2015 18:59:55 +0300 Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file Message-ID: <552FDC7B.1020902@oracle.com> Everybody, Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/ With current testing infrastructure it's hard to make file unreadable on all platforms. From the other side codepath triggered by file open error is covered by the case: "Read a directory - verify the read fails" So I decide to go with the surgery rather than a therapy and cut out this test case entirely. -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 erik.gahlin at oracle.com Thu Apr 16 16:30:47 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 16 Apr 2015 18:30:47 +0200 Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file In-Reply-To: <552FDC7B.1020902@oracle.com> References: <552FDC7B.1020902@oracle.com> Message-ID: <552FE3B7.8000103@oracle.com> Looks good Erik Dmitry Samersoff skrev 2015-04-16 17:59: > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/ > > With current testing infrastructure it's hard to make file unreadable > on all platforms. > > From the other side codepath triggered by file open error is covered by > the case: "Read a directory - verify the read fails" > > So I decide to go with the surgery rather than a therapy and cut out > this test case entirely. > > -Dmitry > From daniel.daugherty at oracle.com Thu Apr 16 17:01:29 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Apr 2015 11:01:29 -0600 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552832AF.8080204@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> Message-ID: <552FEAE9.6020103@oracle.com> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/classfile/javaClasses.cpp No comments. src/share/vm/oops/cpCache.hpp No comments. src/share/vm/oops/cpCache.cpp No comments. src/share/vm/prims/methodHandles.hpp No comments. src/share/vm/prims/methodHandles.cpp Now we get to the meat of the change. :-) Instead of the double iteration loop in the old code, you are now taking advantage of the recent 'orig_method_idnum()' work. So you are not only reducing the iteration count, you are also reducing the number of adjustment calls that need to be made. Cool. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. Thumbs up. Do you happen to have any info on perf improvements for this fix? No big deal if you don't. Dan On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > This is the second class redefinition scalability/optimization fix > that is in my queue to push into 9 and 8u60. > > The approach is similar to the first one but much smaller. > For convenience, these are the links to the first scalability fix: > Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > Please, let me know if you have any chance to review this. > This is the last one that is waiting for your attention! :) > > Thanks, > Serguei > > On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8073705 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >> >> >> >> Summary: >> >> This is the 2-nd round of performance/calability fixes in class >> redefinition. >> This time, the two remaining issues that were left alone in the >> first round fix: >> - optimized ConstantPoolCache::adjust_method_entries() is used >> for previous versions >> - the MemberNameTable::adjust_method_entries() has been >> optimized too >> - some cleanup >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG >> java/lang/instrument, com/sun/jdi >> >> >> Thanks, >> Serguei >> > From staffan.larsen at oracle.com Fri Apr 17 06:27:45 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Apr 2015 08:27:45 +0200 Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file In-Reply-To: <552FDC7B.1020902@oracle.com> References: <552FDC7B.1020902@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 16 apr 2015, at 17:59, Dmitry Samersoff wrote: > > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/ > > With current testing infrastructure it's hard to make file unreadable > on all platforms. > > From the other side codepath triggered by file open error is covered by > the case: "Read a directory - verify the read fails" > > So I decide to go with the surgery rather than a therapy and cut out > this test case entirely. > > -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 fredrik.arvidsson at oracle.com Fri Apr 17 07:32:33 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 09:32:33 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... Message-ID: <5530B711.2070009@oracle.com> Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From mattis.castegren at oracle.com Fri Apr 17 07:55:43 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 00:55:43 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> Hi Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like log("gc,g1,init", )? Also, will all tags be defined in one file so that you can see which modules exists? Kind Regards /Mattis -----Original Message----- From: Fredrik Arvidsson Sent: den 17 april 2015 09:33 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Updates to JEP-158: JVM Unified Logging are coming... Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From fredrik.arvidsson at oracle.com Fri Apr 17 08:13:44 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 10:13:44 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> Message-ID: <5530C0B8.5020701@oracle.com> Hi Mattis The hierarchical structure is gone. Each log line in the code should contain all tags related to the message logged. In your example below the line would be printed just like before since the log call contains the gc tag. All tags will be defined in a single source file. The available tags will just like before be enumerable in runtime. /Fredrik On 2015-04-17 09:55, Mattis Castegren wrote: > Hi > > Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like > log("gc,g1,init", )? > > Also, will all tags be defined in one file so that you can see which modules exists? > > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 09:33 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Updates to JEP-158: JVM Unified Logging are coming... > > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel > we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by > the logging functionality in JRockit JVM. The JEP was updated and > refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal > would work, and the JEP was targeted for JDK 9 and the implementation > work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the > JEP, this time with greater force. At this point we decided to take a > time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout > to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this > is logging in the 'metaspace' code. The functionality in the 'metaspace > area' can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these > two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation > has been narrowed down some to enable us to deliver good value as soon > as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and > at the same time it allows any interested party to try out and follow > the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From mattis.castegren at oracle.com Fri Apr 17 08:27:53 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 01:27:53 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530C0B8.5020701@oracle.com> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> Message-ID: <26421508-9c07-45e5-a109-1b148272c862@default> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like log ("gc,g1,g1_init", ...) If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." Kind Regards /Mattis -----Original Message----- From: Fredrik Arvidsson Sent: den 17 april 2015 10:14 To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... Hi Mattis The hierarchical structure is gone. Each log line in the code should contain all tags related to the message logged. In your example below the line would be printed just like before since the log call contains the gc tag. All tags will be defined in a single source file. The available tags will just like before be enumerable in runtime. /Fredrik On 2015-04-17 09:55, Mattis Castegren wrote: > Hi > > Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like > log("gc,g1,init", )? > > Also, will all tags be defined in one file so that you can see which modules exists? > > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 09:33 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Updates to JEP-158: JVM Unified Logging are coming... > > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel > we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by > the logging functionality in JRockit JVM. The JEP was updated and > refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal > would work, and the JEP was targeted for JDK 9 and the implementation > work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the > JEP, this time with greater force. At this point we decided to take a > time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout > to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this > is logging in the 'metaspace' code. The functionality in the 'metaspace > area' can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these > two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation > has been narrowed down some to enable us to deliver good value as soon > as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and > at the same time it allows any interested party to try out and follow > the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From fredrik.arvidsson at oracle.com Fri Apr 17 09:29:58 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 11:29:58 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <26421508-9c07-45e5-a109-1b148272c862@default> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> <26421508-9c07-45e5-a109-1b148272c862@default> Message-ID: <5530D296.9000408@oracle.com> Hi Ill try to reply in-line below. On 2015-04-17 10:27, Mattis Castegren wrote: > Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one. There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent. If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly. There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong? > If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like > > log ("gc,g1,g1_init", ...) > > If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :( Cheers /Fredrik > Kind Regards > /Mattis > > -----Original Message----- > From: Fredrik Arvidsson > Sent: den 17 april 2015 10:14 > To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... > > Hi Mattis > > The hierarchical structure is gone. Each log line in the code should > contain all tags related to the message logged. > In your example below the line would be printed just like before since > the log call contains the gc tag. > > All tags will be defined in a single source file. The available tags > will just like before be enumerable in runtime. > > /Fredrik > > On 2015-04-17 09:55, Mattis Castegren wrote: >> Hi >> >> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like >> log("gc,g1,init", )? >> >> Also, will all tags be defined in one file so that you can see which modules exists? >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Fredrik Arvidsson >> Sent: den 17 april 2015 09:33 >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers >> Subject: Updates to JEP-158: JVM Unified Logging are coming... >> >> Hi >> >> We are planning to release an updated version of JEP-158 very soon. The >> work to update this JEP has been going on for some time and we now feel >> we are ready to present it to a wider audience. >> >> The JEP for JVM Unified Logging was created back in February 2012. The >> requirements for the API and implementation were heavily influenced by >> the logging functionality in JRockit JVM. The JEP was updated and >> refined in mid 2014 and eventually targeted for JDK 9 in late 2014: >> https://bugs.openjdk.java.net/browse/JDK-8046148 >> >> During the review process of the JEP some concerns were voiced about the >> chosen API and functionality but the conclusion was that the proposal >> would work, and the JEP was targeted for JDK 9 and the implementation >> work was started. >> >> Early 2015 during pre-reviews and presentations of the API and >> implementation concerns were again raised about the formulation of the >> JEP, this time with greater force. At this point we decided to take a >> time-out and investigate our options going forward. >> >> The time-out led to a modified proposal that can be found here: >> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html >> and with some illustrations here: >> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png >> >> So what have we changed, and why? >> In short we have switched from using an hierarchical log subject layout >> to something that could be best described as a tag based solution. >> >> The main reason for the change of the logging API is that we have found >> that some logging can't easily be ordered under a single hierarchical >> subject but can belong to multiple subjects/areas. One example of this >> is logging in the 'metaspace' code. The functionality in the 'metaspace >> area' can be called from both GC and Runtime code. Another example is >> class-unloading. There are more examples on this of course, but these >> two we think are very clear and easy to understand. >> >> The core functionality of the logging framework is not changed that much >> from the earlier proposal. We have tried to make it leaner and not as >> verbose (functionality wise) as before. The scope of the implementation >> has been narrowed down some to enable us to deliver good value as soon >> as possible. >> >> Our plan is as follows: >> After getting initial feedback from the community about the new proposal >> we will update the JEP description. We aim to do this early next week. >> We are planning to use the JDK9 sandbox repository during development. >> This enables us who are implementing it to work in an efficient way and >> at the same time it allows any interested party to try out and follow >> the work during the implementation phase. >> >> More information about the sandbox repository name and other >> practicalities will follow shortly. >> >> Cheers >> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. From martijnverburg at gmail.com Fri Apr 17 10:12:55 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 17 Apr 2015 12:12:55 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: Hi Fredrik, Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction. One quick bit of feedback. Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. Cheers, Martijn On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel we > are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by the > logging functionality in JRockit JVM. The JEP was updated and refined in > mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal would > work, and the JEP was targeted for JDK 9 and the implementation work was > started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the JEP, > this time with greater force. At this point we decided to take a time-out > and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to > something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this is > logging in the 'metaspace' code. The functionality in the 'metaspace area' > can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these two > we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation has > been narrowed down some to enable us to deliver good value as soon as > possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and at > the same time it allows any interested party to try out and follow the work > during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik.arvidsson at oracle.com Fri Apr 17 12:36:05 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 17 Apr 2015 14:36:05 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: References: <5530B711.2070009@oracle.com> Message-ID: <5530FE35.3010107@oracle.com> Hi Martijn, and the others :) I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. Cheers /Fredrik On 2015-04-17 12:12, Martijn Verburg wrote: > Hi Fredrik, > > Thanks from us (jClarity and some other orgs) for considering the tag > based system, we're really glad you've gone in this direction. One > quick bit of feedback. > > Is it possible to add a binary / compressed logging format or an > interface/ API to plug one in for high performance Logging? Human > readable is nice for looking at logs immediately, but for some of our > customers they'd be looking to offload that concern to another > process/host. > > Cheers, > Martijn > > On 17 April 2015 at 09:32, Fredrik Arvidsson > > > wrote: > > Hi > > We are planning to release an updated version of JEP-158 very > soon. The work to update this JEP has been going on for some time > and we now feel we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. > The requirements for the API and implementation were heavily > influenced by the logging functionality in JRockit JVM. The JEP > was updated and refined in mid 2014 and eventually targeted for > JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced > about the chosen API and functionality but the conclusion was that > the proposal would work, and the JEP was targeted for JDK 9 and > the implementation work was started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of > the JEP, this time with greater force. At this point we decided to > take a time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject > layout to something that could be best described as a tag based > solution. > > The main reason for the change of the logging API is that we have > found that some logging can't easily be ordered under a single > hierarchical subject but can belong to multiple subjects/areas. > One example of this is logging in the 'metaspace' code. The > functionality in the 'metaspace area' can be called from both GC > and Runtime code. Another example is class-unloading. There are > more examples on this of course, but these two we think are very > clear and easy to understand. > > The core functionality of the logging framework is not changed > that much from the earlier proposal. We have tried to make it > leaner and not as verbose (functionality wise) as before. The > scope of the implementation has been narrowed down some to enable > us to deliver good value as soon as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new > proposal we will update the JEP description. We aim to do this > early next week. > We are planning to use the JDK9 sandbox repository during > development. This enables us who are implementing it to work in an > efficient way and at the same time it allows any interested party > to try out and follow the work during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattis.castegren at oracle.com Fri Apr 17 13:16:32 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 17 Apr 2015 06:16:32 -0700 (PDT) Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530FE35.3010107@oracle.com> References: <5530B711.2070009@oracle.com> <5530FE35.3010107@oracle.com> Message-ID: I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools. ? But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control? ? Kind Regards /Mattis ? From: Fredrik Arvidsson Sent: den 17 april 2015 14:36 To: Martijn Verburg Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... ? Hi Martijn, and the others :) I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. Cheers /Fredrik On 2015-04-17 12:12, Martijn Verburg wrote: Hi Fredrik, ? Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction.? One quick bit of feedback. ? Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging?? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. Cheers, Martijn ? On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: Hi We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: https://bugs.openjdk.java.net/browse/JDK-8046148 During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. The time-out led to a modified proposal that can be found here: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html and with some illustrations here: HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png So what have we changed, and why? In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. Our plan is as follows: After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. More information about the sandbox repository name and other practicalities will follow shortly. Cheers Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Fri Apr 17 14:35:18 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 17 Apr 2015 16:35:18 +0200 Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken In-Reply-To: <552E9EB1.6070607@oracle.com> References: <552E9EB1.6070607@oracle.com> Message-ID: Thanks for the reviews, Vladimir, Dmitry and Staffan. Roland. From serguei.spitsyn at oracle.com Fri Apr 17 20:04:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Apr 2015 13:04:54 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552FEAE9.6020103@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <552FEAE9.6020103@oracle.com> Message-ID: <55316766.6080901@oracle.com> On 4/16/15 10:01 AM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ > > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/classfile/javaClasses.cpp > No comments. > > src/share/vm/oops/cpCache.hpp > No comments. > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/prims/methodHandles.hpp > No comments. > > src/share/vm/prims/methodHandles.cpp > Now we get to the meat of the change. :-) > > Instead of the double iteration loop in the old code, you > are now taking advantage of the recent 'orig_method_idnum()' > work. So you are not only reducing the iteration count, you > are also reducing the number of adjustment calls that need > to be made. Cool. Thanks! > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > > Thumbs up. Thanks for the review! > > Do you happen to have any info on perf improvements for this > fix? No big deal if you don't. I do not have any info on perf improvements for this fix. The plan is to ask EM team to check if they still have any scalability issues after both fixes and see what are the improvements. They report that class retransformations in the EM take tens of minutes. Thanks, Serguei > > Dan > > > On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen and Dan, >> >> This is the second class redefinition scalability/optimization fix >> that is in my queue to push into 9 and 8u60. >> >> The approach is similar to the first one but much smaller. >> For convenience, these are the links to the first scalability fix: >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> Please, let me know if you have any chance to review this. >> This is the last one that is waiting for your attention! :) >> >> Thanks, >> Serguei >> >> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>> >>> >>> >>> Summary: >>> >>> This is the 2-nd round of performance/calability fixes in class >>> redefinition. >>> This time, the two remaining issues that were left alone in the >>> first round fix: >>> - optimized ConstantPoolCache::adjust_method_entries() is used >>> for previous versions >>> - the MemberNameTable::adjust_method_entries() has been >>> optimized too >>> - some cleanup >>> >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG >>> java/lang/instrument, com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From kirk at kodewerk.com Fri Apr 17 20:34:16 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 17 Apr 2015 22:34:16 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: References: <5530B711.2070009@oracle.com> <5530FE35.3010107@oracle.com> Message-ID: <3C32C2F5-68F1-4B55-80FD-C62D98A6A996@kodewerk.com> Hi All, I?m very happy for a digital solution. As for solving problems in JFR.. great but that is a commercial solution and thus doesn?t work for OpenJDK. Remember? Plus, with all due respect for JFR, not all of us agree that this is the best way to sort out performance issues ;-) Regards, Kirk On Apr 17, 2015, at 3:16 PM, Mattis Castegren wrote: > I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools. > > > > But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control? > > > > Kind Regards > > /Mattis > > > > From: Fredrik Arvidsson > Sent: den 17 april 2015 14:36 > To: Martijn Verburg > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers > Subject: Re: Updates to JEP-158: JVM Unified Logging are coming... > > > > Hi Martijn, and the others :) > > I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume. > > Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans. > > There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for. > > As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed. > > Cheers > /Fredrik > > On 2015-04-17 12:12, Martijn Verburg wrote: > > Hi Fredrik, > > > > Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction. One quick bit of feedback. > > > > Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host. > > > > > Cheers, > Martijn > > > > On 17 April 2015 at 09:32, Fredrik Arvidsson wrote: > > Hi > > We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started. > > Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase. > > More information about the sandbox repository name and other practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kirk at kodewerk.com Fri Apr 17 20:40:15 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 17 Apr 2015 22:40:15 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530D296.9000408@oracle.com> References: <5530B711.2070009@oracle.com> <132d6a7d-26a7-466a-b567-0cf662a87d0c@default> <5530C0B8.5020701@oracle.com> <26421508-9c07-45e5-a109-1b148272c862@default> <5530D296.9000408@oracle.com> Message-ID: On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson wrote: > Hi > Ill try to reply in-line below. > > On 2015-04-17 10:27, Mattis Castegren wrote: >> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc. > Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one. Indeed! > > There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent. My recommendation to teams has always been to give architectural guidelines or use requirements from operations to define logging. If you leave logging to dev it?s generally useful for dev and no one else. > > If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly. JMS has a spec for managing this type of behavior. > > There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong? >> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like >> >> log ("gc,g1,g1_init", ...) >> >> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..." > Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :( Make them manageable so if you forget on the command line you can change them on the fly. Regards, Kirk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From thomas.stuefe at gmail.com Sat Apr 18 18:02:45 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 18 Apr 2015 20:02:45 +0200 Subject: Updates to JEP-158: JVM Unified Logging are coming... In-Reply-To: <5530B711.2070009@oracle.com> References: <5530B711.2070009@oracle.com> Message-ID: Hi Frederik, I like this proposal a lot, especially the abandonment of a hierarchical structure in favor of tags. In the SAPJVM we have a tracing system in many details similar to the one proposed here. We will be probably abandon it and switch to the official logging system once it is implemented in the OpenJDK. Some questions/remarks: 1 Will logging be available from native JDK code too, not only from within the hotspot? 2 Will there a way to cover early logging? One common problem is logging during initialization time of the VM, and there is always the problem whether logging system is already initialized ("I don't see my trace - did I just not hit it or was logging not up yet?"). Would be very nice if this problem were covered, e.g. by capturing output in-memory and writing it out delayed once logging subsystem is up. 3 A similar problem is that logging should use as little VM infrastructure as possible, to make it possible to use it from all VM code. If you agree with (2) and (3), it may make sense to add some explicit requirements to the JEP. 4 "Stretch Goal: Ability to configure in which order decorations should be printed" In our tracing system we also have decorations, and we even added a feature to give the user the ability to format it itself, by adding a format-string like feature (-XtraceFormat="blabla @PID @TID @USER"). This looked like a neat idea, but we found in practice over the years that this feature was very rarely used. So maybe this stretch goal is not needed. 5 Would be nice to have short alternative names for the decorators, maybe even single letters 6 "The different log levels should have guidelines that define the expected performance overhead for the level. " It also may make sense to add guide lines for the expected verbosity of log levels, either in terms of datasize/time or messages/time. I look forward to this logging system in practice! Kind Regards, Thomas On Fri, Apr 17, 2015 at 9:32 AM, Fredrik Arvidsson < fredrik.arvidsson at oracle.com> wrote: > Hi > > We are planning to release an updated version of JEP-158 very soon. The > work to update this JEP has been going on for some time and we now feel we > are ready to present it to a wider audience. > > The JEP for JVM Unified Logging was created back in February 2012. The > requirements for the API and implementation were heavily influenced by the > logging functionality in JRockit JVM. The JEP was updated and refined in > mid 2014 and eventually targeted for JDK 9 in late 2014: > https://bugs.openjdk.java.net/browse/JDK-8046148 > > During the review process of the JEP some concerns were voiced about the > chosen API and functionality but the conclusion was that the proposal would > work, and the JEP was targeted for JDK 9 and the implementation work was > started. > > Early 2015 during pre-reviews and presentations of the API and > implementation concerns were again raised about the formulation of the JEP, > this time with greater force. At this point we decided to take a time-out > and investigate our options going forward. > > The time-out led to a modified proposal that can be found here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html > and with some illustrations here: > http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png > > So what have we changed, and why? > In short we have switched from using an hierarchical log subject layout to > something that could be best described as a tag based solution. > > The main reason for the change of the logging API is that we have found > that some logging can't easily be ordered under a single hierarchical > subject but can belong to multiple subjects/areas. One example of this is > logging in the 'metaspace' code. The functionality in the 'metaspace area' > can be called from both GC and Runtime code. Another example is > class-unloading. There are more examples on this of course, but these two > we think are very clear and easy to understand. > > The core functionality of the logging framework is not changed that much > from the earlier proposal. We have tried to make it leaner and not as > verbose (functionality wise) as before. The scope of the implementation has > been narrowed down some to enable us to deliver good value as soon as > possible. > > Our plan is as follows: > After getting initial feedback from the community about the new proposal > we will update the JEP description. We aim to do this early next week. > We are planning to use the JDK9 sandbox repository during development. > This enables us who are implementing it to work in an efficient way and at > the same time it allows any interested party to try out and follow the work > during the implementation phase. > > More information about the sandbox repository name and other > practicalities will follow shortly. > > Cheers > Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Mon Apr 20 13:53:19 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 20 Apr 2015 22:53:19 +0900 Subject: PING: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <55003F77.80606@gmail.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> <54DF4956.7030709@gmail.com> <55003F77.80606@gmail.com> Message-ID: <553504CF.8080904@gmail.com> Hi all, I've uploaded webrev for this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ Thanks, Yasumasa On 2015/03/11 22:13, Yasumasa Suenaga wrote: > Hi all, > >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run >> to it. > > I've uploaded new webrev, and I've applied it to new patch. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ > > I also updated jtreg testcase. > It works fine in my environment. > > > Thanks, > > Yasumasa > > > On 2015/02/14 22:10, Yasumasa Suenaga wrote: >> Hi Mikael, >> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run >> >> Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? >> This function is used with GCCause::is_serviceability_requested_gc() . >> CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit() >> >> is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc >> is selected. >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run >> to it. >> >>> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. >> >> We can use GCCause::is_user_requested_gc() if the proposal in above is accepted. >> >> >> Thanks >> >> Yasumasa >> >> >> >> On 2015/02/13 21:33, Mikael Gerdin wrote: >>> Hi Yasumasa, >>> >>> On 2015-02-11 15:02, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >>>> However, it has been backouted because test is failed [1] and it is not considered >>>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >>>> >>>> I've created patch for this enhancement. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ >>> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run >>> >>> Given that the documentation of the GC.run command is: >>> "GC.run >>> Call java.lang.System.gc(). >>> >>> Impact: Medium: Depends on Java heap size and content. >>> >>> Syntax: GC.run" >>> >>> I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). >>> >>> This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC >>> >>> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. >>> >>> /Mikael >>> >>>> >>>> >>>> I'm jdk9 committer, but I'm not employee at Oracle. >>>> So I need a Sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >>>> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >>>> From joe.darcy at oracle.com Mon Apr 20 16:49:33 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 20 Apr 2015 09:49:33 -0700 Subject: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined Message-ID: <55352E1D.8050608@oracle.com> Hello, As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh has been failing for several days across platforms, I think the time has come to mark the test as ignored until the full fix for related bug JDK-8077924: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start failing after JDK-8076221 can be developed. Patch below. Thanks, -Joe diff -r 9b63a16654d5 test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh --- a/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Thu Apr 16 11:33:59 2015 -0700 +++ b/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Mon Apr 20 09:47:52 2015 -0700 @@ -29,6 +29,7 @@ # @library /lib/testlibrary # @build jdk.testlibrary.* TestLogger Utils RmiBootstrapTest # @run shell/timeout=300 RmiSslBootstrapTest.sh +# @ignore 8077924 # Define the Java class test name TESTCLASS="RmiBootstrapTest" From jaroslav.bachorik at oracle.com Mon Apr 20 17:25:32 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 20 Apr 2015 19:25:32 +0200 Subject: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined In-Reply-To: <55352E1D.8050608@oracle.com> References: <55352E1D.8050608@oracle.com> Message-ID: <5535368C.9060106@oracle.com> Looks good! -JB- On 20.4.2015 18:49, joe darcy wrote: > Hello, > > As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > has been failing for several days across platforms, I think the time has > come to mark the test as ignored until the full fix for related bug > > JDK-8077924: > sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start failing > after JDK-8076221 > > can be developed. > > Patch below. > > Thanks, > > -Joe > > diff -r 9b63a16654d5 > test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > --- a/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Thu > Apr 16 11:33:59 2015 -0700 > +++ b/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Mon > Apr 20 09:47:52 2015 -0700 > @@ -29,6 +29,7 @@ > # @library /lib/testlibrary > # @build jdk.testlibrary.* TestLogger Utils RmiBootstrapTest > # @run shell/timeout=300 RmiSslBootstrapTest.sh > +# @ignore 8077924 > > # Define the Java class test name > TESTCLASS="RmiBootstrapTest" > From Alan.Bateman at oracle.com Mon Apr 20 17:44:21 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Apr 2015 18:44:21 +0100 Subject: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined In-Reply-To: <55352E1D.8050608@oracle.com> References: <55352E1D.8050608@oracle.com> Message-ID: <55353AF5.7020801@oracle.com> On 20/04/2015 17:49, joe darcy wrote: > Hello, > > As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > has been failing for several days across platforms, I think the time > has come to mark the test as ignored until the full fix for related bug > > JDK-8077924: > sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start > failing after JDK-8076221 > > can be developed. This looks okay but we mostly use the exclude list (jdk/test/ProblemList.txt) these days in the jdk repo (I realize @ignore is still used in the hotspot repo). -Alan. From shanliang.jiang at oracle.com Tue Apr 21 07:01:29 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Tue, 21 Apr 2015 09:01:29 +0200 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean Message-ID: <5535F5C9.5060408@oracle.com> Hi, Please review this test fix: webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8078144 The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean was removed because HotSpotDiagnosticMXBean is not in java.management module but in jdk.management module, to get the HotSpotDiagnosticMXBean we should call: ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class) I passed all failed tests with the fix. Thanks, Shanliang From Alan.Bateman at oracle.com Tue Apr 21 07:05:56 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Apr 2015 08:05:56 +0100 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean In-Reply-To: <5535F5C9.5060408@oracle.com> References: <5535F5C9.5060408@oracle.com> Message-ID: <5535F6D4.8080300@oracle.com> On 21/04/2015 08:01, Shanliang Jiang wrote: > Hi, > > Please review this test fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8078144 > > The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean > was removed because HotSpotDiagnosticMXBean is not in java.management > module but in jdk.management module, to get the > HotSpotDiagnosticMXBean we should call: > ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class) > > I passed all failed tests with the fix. > I see JInfoRunningProcessFlagTest still imports sun.management.ManagementFactoryHelper. Best to remove that now as otherwise this issue will come back again once javac has support for modules. Otherwise looks okay to me. -Alan. From staffan.larsen at oracle.com Tue Apr 21 07:19:14 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Apr 2015 09:19:14 +0200 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean In-Reply-To: <5535F5C9.5060408@oracle.com> References: <5535F5C9.5060408@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 21 apr 2015, at 09:01, Shanliang Jiang wrote: > > Hi, > > Please review this test fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8078144 > > The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean was removed because HotSpotDiagnosticMXBean is not in java.management module but in jdk.management module, to get the HotSpotDiagnosticMXBean we should call: > ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class) > > I passed all failed tests with the fix. > > Thanks, > Shanliang > > > From shanliang.jiang at oracle.com Tue Apr 21 07:47:25 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Tue, 21 Apr 2015 09:47:25 +0200 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean In-Reply-To: <5535F6D4.8080300@oracle.com> References: <5535F5C9.5060408@oracle.com> <5535F6D4.8080300@oracle.com> Message-ID: <5536008D.9020406@oracle.com> Alan Bateman wrote: > On 21/04/2015 08:01, Shanliang Jiang wrote: >> Hi, >> >> Please review this test fix: >> >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8078144 >> >> The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean >> was removed because HotSpotDiagnosticMXBean is not in java.management >> module but in jdk.management module, to get the >> HotSpotDiagnosticMXBean we should call: >> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class) >> >> I passed all failed tests with the fix. >> > I see JInfoRunningProcessFlagTest still imports > sun.management.ManagementFactoryHelper. Best to remove that now as > otherwise this issue will come back again once javac has support for > modules. Otherwise looks okay to me. OK I have removed that useless import, here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8078144/01/ by the way the test JInfoRunningProcessFlagTest is in jdk/test/ProblemList.txt and I found the issue by "find ./ -name "*.java" |xargs grep ManagementFactoryHelper.getDiagnosticMXBean ". So my fix just makes it compilable but it still fails Thanks, Shanliang From Alan.Bateman at oracle.com Tue Apr 21 08:02:47 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Apr 2015 09:02:47 +0100 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean In-Reply-To: <5536008D.9020406@oracle.com> References: <5535F5C9.5060408@oracle.com> <5535F6D4.8080300@oracle.com> <5536008D.9020406@oracle.com> Message-ID: <55360427.4000908@oracle.com> On 21/04/2015 08:47, Shanliang Jiang wrote: > OK I have removed that useless import, here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8078144/01/ Looks fine. -Alan. From yekaterina.kantserova at oracle.com Tue Apr 21 08:08:11 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 21 Apr 2015 01:08:11 -0700 (PDT) Subject: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined Message-ID: Hi Joe, I would also suggest to put the test on the ProblemList, which is the current practice for jdk repo. Best regards, Katja ----- Original Message ----- From: Alan.Bateman at oracle.com To: joe.darcy at oracle.com, serviceability-dev at openjdk.java.net Sent: Monday, April 20, 2015 7:44:30 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined On 20/04/2015 17:49, joe darcy wrote: > Hello, > > As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > has been failing for several days across platforms, I think the time > has come to mark the test as ignored until the full fix for related bug > > JDK-8077924: > sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start > failing after JDK-8076221 > > can be developed. This looks okay but we mostly use the exclude list (jdk/test/ProblemList.txt) these days in the jdk repo (I realize @ignore is still used in the hotspot repo). -Alan. From mandy.chung at oracle.com Tue Apr 21 15:34:59 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Apr 2015 08:34:59 -0700 Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean In-Reply-To: <5535F5C9.5060408@oracle.com> References: <5535F5C9.5060408@oracle.com> Message-ID: <55366E23.9020105@oracle.com> On 4/21/2015 12:01 AM, Shanliang Jiang wrote: > Hi, > > Please review this test fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8078144 > > The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean > was removed because HotSpotDiagnosticMXBean is not in java.management > module but in jdk.management module, to get the > HotSpotDiagnosticMXBean we should call: > ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class) The webrev.01 version looks good to me. JDK-8042901 fixed several tests to eliminate the dependency on sun.management internal APIs and missed these few tests. You probably may have done this - grep and see if there are any remaining tests to be updated. Mandy From joe.darcy at oracle.com Wed Apr 22 02:13:16 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 21 Apr 2015 19:13:16 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness Message-ID: <553703BC.1070504@oracle.com> Hello, As the next step of implementing "Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness" [1], please review this changeset which adds a "randomness" jtreg keyword and tags 240 regression tests in the jdk repository with the keyword: JDK-8078334: Mark regression tests using randomness http://cr.openjdk.java.net/~darcy/8078334.0/ The update to test/TEST.ROOT is -# The list of keywords supported in the entire test suite -keys=2d dnd i18n intermittent +# The list of keywords supported in the entire test suite. The +# "intermittent" keyword marks tests known to fail intermittently. +# The "randomness" keyword marks tests using randomness with test +# cases differing from run to run. (A test using a fixed random seed +# would not count as "randomness" by this definition.) Extra care +# should be taken to handle test failures of intermittent or +# randomness tests. + +keys=2d dnd i18n intermittent randomness To find the affected files for this fix, I grepped over the regression tests looking for "random" and verified if a random number generated was used in a way where its values would differ from run to run. In particular, as noted above, a java.util.Random random number generator with a fixed seed did *not* qualify a test for the "randomness" keyword. The usual update to the files in this changeset is just + * @key randomness The updated tests are mostly in the core libs and security libs areas with a few serviceability tests too. The list in this bug is not quite exhaustive; I did not include rmi tests or client libraries tests. I verified that running jtreg ... -l -k:randomness . returns the expected number of tests and that the tests continue to pass (or be ignored) when run. One goal of marking the tests using randomness is to help root out some remaining intermittent test failures. If one of the randomness tests is observed to fail intermittently, if it has not already been updated to print out the random seed and be able to accept a particular seed when run, the test should be so modified so that future failures can log the seed value in hopes of reproducing the failure. Brian Burkhalter has proactively made these sorts of changes to the java.math tests earlier in JDK 9. [2] Since most of the randomness tests don't have a history of instability (and due to the unexpected large number of them!), I don't think it is necessary to proactively update all the other tests without evidence of a history of failure. However, when an otherwise unexplained failure is seen, I recommend applying the sort of updates Brian has done in java.math to the failing test(s). Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html [2] JDK-8074460, Always print seeds used in [Splittable]Random instances in java.math tests, https://bugs.openjdk.java.net/browse/JDK-8074460 From daniel.fuchs at oracle.com Wed Apr 22 08:31:47 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Apr 2015 10:31:47 +0200 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553703BC.1070504@oracle.com> References: <553703BC.1070504@oracle.com> Message-ID: <55375C73.7060001@oracle.com> On 22/04/15 04:13, Joseph D. Darcy wrote: > One goal of marking the tests using randomness is to help root out some > remaining intermittent test failures. If one of the randomness tests is > observed to fail intermittently, if it has not already been updated to > print out the random seed and be able to accept a particular seed when > run, the test should be so modified so that future failures can log the > seed value in hopes of reproducing the failure. Hi Joe, The following logging tests use UUID.randomUUID() to generate a 'unique' file name in order to avoid possible collision if these tests are run concurrently or if some files have been left over from a previous run (some of these use %t - the temporary directory - which has been known to cause intermittent failure in those cases). So I believe that removing randomness, or attempting to make it predictable, would in those specific cases make those tests more prone to intermittent failures. In this light - should these tests still be tagged with the @randomness keyword? test/java/util/logging/CheckZombieLockTest.java test/java/util/logging/FileHandlerLongLimit.java test/java/util/logging/FileHandlerPath.java test/java/util/logging/FileHandlerPatternExceptions.java test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java best regards, -- daniel From yekaterina.kantserova at oracle.com Wed Apr 22 09:17:10 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 11:17:10 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Message-ID: <55376716.10806@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8059047 webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. The old jhat packages have been moved as follows: com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util The source has not been changed except Copyrights year. Thanks, Katja From yekaterina.kantserova at oracle.com Wed Apr 22 10:56:28 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 12:56:28 +0200 Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK Message-ID: <55377E5C.3090404@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8076524 webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00 This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). Thanks, Katja From Alan.Bateman at oracle.com Wed Apr 22 11:09:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Apr 2015 12:09:30 +0100 Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK In-Reply-To: <55377E5C.3090404@oracle.com> References: <55377E5C.3090404@oracle.com> Message-ID: <5537816A.4020103@oracle.com> On 22/04/2015 11:56, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8076524 > webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00 > > This fix is a part of JEP 241: Remove the jhat Tool > (https://bugs.openjdk.java.net/browse/JDK-8059039). This looks okay to me although I would have expected these tests to be removed as part of the change to remove jhat (no issue with it being split into multiple changes, just wondering why it is being done this way). -Alan From staffan.larsen at oracle.com Wed Apr 22 11:17:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 13:17:53 +0200 Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK In-Reply-To: <55377E5C.3090404@oracle.com> References: <55377E5C.3090404@oracle.com> Message-ID: <98BB76C4-35EF-48C3-AFE5-D34735C15933@oracle.com> Looks good! Thanks, /Staffan > On 22 apr 2015, at 12:56, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8076524 > webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00 > > This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Apr 22 11:18:45 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 13:18:45 +0200 Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK In-Reply-To: <5537816A.4020103@oracle.com> References: <55377E5C.3090404@oracle.com> <5537816A.4020103@oracle.com> Message-ID: <55378395.4000004@oracle.com> Hi Alan, Thank you for looking at it! When JEP was created the work has been divided in product and test parts according to the JEP guidelines. That's the reason I can come up with. To test part belongs even https://bugs.openjdk.java.net/browse/JDK-8059047. That's would be great if you can take a look at it as well. // Katja On 04/22/2015 01:09 PM, Alan Bateman wrote: > On 22/04/2015 11:56, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8076524 >> webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00 >> >> This fix is a part of JEP 241: Remove the jhat Tool >> (https://bugs.openjdk.java.net/browse/JDK-8059039). > This looks okay to me although I would have expected these tests to be > removed as part of the change to remove jhat (no issue with it being > split into multiple changes, just wondering why it is being done this > way). > > -Alan From staffan.larsen at oracle.com Wed Apr 22 11:20:15 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 13:20:15 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <55376716.10806@oracle.com> References: <55376716.10806@oracle.com> Message-ID: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> Looks good! Thanks, /Staffan > On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8059047 > webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ > > This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. > > The old jhat packages have been moved as follows: > com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model > com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser > com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util > > The source has not been changed except Copyrights year. > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Apr 22 12:25:05 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 14:25:05 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> Message-ID: <55379321.1090403@oracle.com> Staffan, thank you for the review! This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. // Katja On 04/22/2015 01:20 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >> >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >> >> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >> >> The old jhat packages have been moved as follows: >> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >> >> The source has not been changed except Copyrights year. >> >> Thanks, >> Katja From staffan.larsen at oracle.com Wed Apr 22 13:05:03 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:05:03 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <55379321.1090403@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> Message-ID: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> I think you are missing a "@build jdk.test.lib.hprof..*?. /Staffan > On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: > > Staffan, thank you for the review! > > This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. > > // Katja > > > > On 04/22/2015 01:20 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>> >>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>> >>> The old jhat packages have been moved as follows: >>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>> >>> The source has not been changed except Copyrights year. >>> >>> Thanks, >>> Katja > From staffan.larsen at oracle.com Wed Apr 22 13:06:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:06:53 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> Message-ID: I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh /Staffan > On 22 apr 2015, at 15:05, Staffan Larsen wrote: > > I think you are missing a "@build jdk.test.lib.hprof..*?. > > /Staffan > >> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >> >> Staffan, thank you for the review! >> >> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >> >> // Katja >> >> >> >> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>> >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>> >>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>> >>>> The old jhat packages have been moved as follows: >>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>> >>>> The source has not been changed except Copyrights year. >>>> >>>> Thanks, >>>> Katja >> > From staffan.larsen at oracle.com Wed Apr 22 13:09:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Apr 2015 15:09:30 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> Message-ID: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> Oh, and: serviceability/dcmd/gc/HeapDumpTest.java > On 22 apr 2015, at 15:06, Staffan Larsen wrote: > > I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh > > /Staffan > >> On 22 apr 2015, at 15:05, Staffan Larsen wrote: >> >> I think you are missing a "@build jdk.test.lib.hprof..*?. >> >> /Staffan >> >>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >>> >>> Staffan, thank you for the review! >>> >>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >>> >>> // Katja >>> >>> >>> >>> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>>> >>>>> The old jhat packages have been moved as follows: >>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> The source has not been changed except Copyrights year. >>>>> >>>>> Thanks, >>>>> Katja >>> >> > From amy.lu at oracle.com Wed Apr 22 11:19:39 2015 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 22 Apr 2015 19:19:39 +0800 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55375C73.7060001@oracle.com> References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com> Message-ID: <553783CB.7050902@oracle.com> On 4/22/15 4:31 PM, Daniel Fuchs wrote: > On 22/04/15 04:13, Joseph D. Darcy wrote: >> One goal of marking the tests using randomness is to help root out some >> remaining intermittent test failures. If one of the randomness tests is >> observed to fail intermittently, if it has not already been updated to >> print out the random seed and be able to accept a particular seed when >> run, the test should be so modified so that future failures can log the >> seed value in hopes of reproducing the failure. > > Hi Joe, > > The following logging tests use UUID.randomUUID() to generate > a 'unique' file name in order to avoid possible collision if > these tests are run concurrently or if some files have been > left over from a previous run (some of these use %t - the temporary > directory - which has been known to cause intermittent > failure in those cases). > > So I believe that removing randomness, or attempting to > make it predictable, would in those specific cases make > those tests more prone to intermittent failures. > > In this light - should these tests still be tagged with > the @randomness keyword? > > test/java/util/logging/CheckZombieLockTest.java > test/java/util/logging/FileHandlerLongLimit.java > test/java/util/logging/FileHandlerPath.java > test/java/util/logging/FileHandlerPatternExceptions.java > test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > > > > best regards, > > -- daniel I notice similar case in below tests: test/java/util/zip/ZipFile/FinalizeZipFile.java Test need some zip file to test on. Random is used to generate the zip file name. test/java/util/zip/ZipFile/ReadZip.java Random is used to generate a non-existing file name for negative test @randomness might not needed for following tests where test need a zip file to test on, and Random is used to fill some content to the file in createZipFile(). test/java/util/zip/ZipFile/MultiThreadedReadTest.java test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Thanks, Amy From yekaterina.kantserova at oracle.com Wed Apr 22 17:02:13 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Apr 2015 10:02:13 -0700 (PDT) Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Message-ID: <02db0e73-b01d-4b1a-a963-89e4c956f0bc@default> Thanks for the catch Staffan! I'll go through all of them and send out a new webrev. // Katja ----- Original Message ----- From: staffan.larsen at oracle.com To: staffan.larsen at oracle.com Cc: yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Wednesday, April 22, 2015 3:09:35 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(M): 8059047: Extract parser/validator from jhat for use in tests Oh, and: serviceability/dcmd/gc/HeapDumpTest.java > On 22 apr 2015, at 15:06, Staffan Larsen wrote: > > I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh > > /Staffan > >> On 22 apr 2015, at 15:05, Staffan Larsen wrote: >> >> I think you are missing a "@build jdk.test.lib.hprof..*?. >> >> /Staffan >> >>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote: >>> >>> Staffan, thank you for the review! >>> >>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test. >>> >>> // Katja >>> >>> >>> >>> On 04/22/2015 01:20 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>>> >>>>> The old jhat packages have been moved as follows: >>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> The source has not been changed except Copyrights year. >>>>> >>>>> Thanks, >>>>> Katja >>> >> > From joe.darcy at oracle.com Wed Apr 22 17:02:57 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 22 Apr 2015 10:02:57 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55375C73.7060001@oracle.com> References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com> Message-ID: <5537D441.1070204@oracle.com> Hi Daniel, On 4/22/2015 1:31 AM, Daniel Fuchs wrote: > On 22/04/15 04:13, Joseph D. Darcy wrote: >> One goal of marking the tests using randomness is to help root out some >> remaining intermittent test failures. If one of the randomness tests is >> observed to fail intermittently, if it has not already been updated to >> print out the random seed and be able to accept a particular seed when >> run, the test should be so modified so that future failures can log the >> seed value in hopes of reproducing the failure. > > Hi Joe, > > The following logging tests use UUID.randomUUID() to generate > a 'unique' file name in order to avoid possible collision if > these tests are run concurrently or if some files have been > left over from a previous run (some of these use %t - the temporary > directory - which has been known to cause intermittent > failure in those cases). > > So I believe that removing randomness, or attempting to > make it predictable, would in those specific cases make > those tests more prone to intermittent failures. > > In this light - should these tests still be tagged with > the @randomness keyword? > > test/java/util/logging/CheckZombieLockTest.java > test/java/util/logging/FileHandlerLongLimit.java > test/java/util/logging/FileHandlerPath.java > test/java/util/logging/FileHandlerPatternExceptions.java > test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > > The randomness label is just meant to be documentation and not pejorative. Its uses in the tests you identify it is more likely to increase rather than decrease stability. However, I still think it is appropriate to mark these tests for their behavior. Thanks, -Joe From staffan.larsen at oracle.com Thu Apr 23 12:06:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 14:06:27 +0200 Subject: RFR: 8076473 Remove the jhat code and update makefiles Message-ID: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread). JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 bug: https://bugs.openjdk.java.net/browse/JDK-8076473 webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Apr 23 12:15:14 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Apr 2015 13:15:14 +0100 Subject: RFR: 8076473 Remove the jhat code and update makefiles In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> Message-ID: <5538E252.9040006@oracle.com> On 23/04/2015 13:06, Staffan Larsen wrote: > Please review this change to remove the jhat tool. I will not push > this change until the tests have been removed (see a different review > thread). > > JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 > bug: https://bugs.openjdk.java.net/browse/JDK-8076473 > > webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ > > webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ > > This looks good to me, and I assume Katja's patch from yesterday got all the tests. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Apr 23 12:38:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 23 Apr 2015 14:38:48 +0200 Subject: RFR 8077953: [TEST_BUG] com/sun/management/OperatingSystemMXBean/TestTotalSwap.java Compilation failed after JDK-8077387 Message-ID: <5538E7D8.3020303@oracle.com> Please, review this JDK8 only test change Issue : https://bugs.openjdk.java.net/browse/JDK-8077953 Webrev: http://cr.openjdk.java.net/~jbachorik/8077953/webrev.00 Backport of https://bugs.openjdk.java.net/browse/JDK-8077387 requires testlibrary functionality not yet backported to JDK8. This patch takes care of bringing that functionality there. Thanks, -JB- From staffan.larsen at oracle.com Thu Apr 23 13:22:50 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 15:22:50 +0200 Subject: RFR 8077953: [TEST_BUG] com/sun/management/OperatingSystemMXBean/TestTotalSwap.java Compilation failed after JDK-8077387 In-Reply-To: <5538E7D8.3020303@oracle.com> References: <5538E7D8.3020303@oracle.com> Message-ID: <9DD9F27E-6F05-4AA1-998E-CB97357078DF@oracle.com> Looks good! (assuming you ran through the tests successfully) Thanks, /Staffan > On 23 apr 2015, at 14:38, Jaroslav Bachorik wrote: > > Please, review this JDK8 only test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8077953 > Webrev: http://cr.openjdk.java.net/~jbachorik/8077953/webrev.00 > > Backport of https://bugs.openjdk.java.net/browse/JDK-8077387 requires testlibrary functionality not yet backported to JDK8. This patch takes care of bringing that functionality there. > > Thanks, > > -JB- From staffan.larsen at oracle.com Thu Apr 23 14:13:23 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 16:13:23 +0200 Subject: RFR: 8078519 Can't run SA tools from a non-images build Message-ID: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> Please see description of the problem in the bug report: https://bugs.openjdk.java.net/browse/JDK-8078519 The simple fix is included below. Thanks, /Staffan diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java @@ -259,7 +259,12 @@ saProps = new Properties(); URL url = null; try { - url = VM.class.getClassLoader().getResource("sa.properties"); + if (VM.class.getClassLoader() == null) { + url = ClassLoader.getSystemResource("sa.properties"); + } + else { + url = VM.class.getClassLoader().getResource("sa.properties"); + } saProps.load(new BufferedInputStream(url.openStream())); } catch (Exception e) { System.err.println("Unable to load properties " + -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Apr 23 14:51:11 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Apr 2015 16:51:11 +0200 Subject: RFR: 8078519 Can't run SA tools from a non-images build In-Reply-To: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> Message-ID: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> Here is an improved and simplified patch: diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java @@ -259,8 +259,7 @@ saProps = new Properties(); URL url = null; try { - url = VM.class.getClassLoader().getResource("sa.properties"); - saProps.load(new BufferedInputStream(url.openStream())); + saProps.load(VM.class.getResourceAsStream("/sa.properties")); } catch (Exception e) { System.err.println("Unable to load properties " + (url == null ? "null" : url.toString()) + > On 23 apr 2015, at 16:13, Staffan Larsen wrote: > > Please see description of the problem in the bug report: https://bugs.openjdk.java.net/browse/JDK-8078519 > > The simple fix is included below. > > Thanks, > /Staffan > > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -259,7 +259,12 @@ > saProps = new Properties(); > URL url = null; > try { > - url = VM.class.getClassLoader().getResource("sa.properties"); > + if (VM.class.getClassLoader() == null) { > + url = ClassLoader.getSystemResource("sa.properties"); > + } > + else { > + url = VM.class.getClassLoader().getResource("sa.properties"); > + } > saProps.load(new BufferedInputStream(url.openStream())); > } catch (Exception e) { > System.err.println("Unable to load properties " + -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Apr 23 15:12:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Apr 2015 16:12:05 +0100 Subject: RFR: 8078519 Can't run SA tools from a non-images build In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> Message-ID: <55390BC5.7050300@oracle.com> On 23/04/2015 15:51, Staffan Larsen wrote: > Here is an improved and simplified patch: > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -259,8 +259,7 @@ > saProps = new Properties(); > URL url = null; > try { > - url = VM.class.getClassLoader().getResource("sa.properties"); > - saProps.load(new BufferedInputStream(url.openStream())); > + saProps.load(VM.class.getResourceAsStream("/sa.properties")); > } catch (Exception e) { > System.err.println("Unable to load properties " + > (url == null ? "null" : > url.toString()) + > > This looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Apr 23 15:22:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Apr 2015 08:22:56 -0700 Subject: RFR: 8076473 Remove the jhat code and update makefiles In-Reply-To: <5538E252.9040006@oracle.com> References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> <5538E252.9040006@oracle.com> Message-ID: <55390E50.1050209@oracle.com> Looks good to me. /Erik On 2015-04-23 05:15, Alan Bateman wrote: > > > On 23/04/2015 13:06, Staffan Larsen wrote: >> Please review this change to remove the jhat tool. I will not push >> this change until the tests have been removed (see a different review >> thread). >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 >> bug: https://bugs.openjdk.java.net/browse/JDK-8076473 >> >> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ >> >> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ >> >> > This looks good to me, and I assume Katja's patch from yesterday got > all the tests. > > -Alan. From mandy.chung at oracle.com Thu Apr 23 16:41:37 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Apr 2015 09:41:37 -0700 Subject: RFR: 8078519 Can't run SA tools from a non-images build In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> Message-ID: <553920C1.7020705@oracle.com> On 04/23/2015 07:51 AM, Staffan Larsen wrote: > Here is an improved and simplified patch: > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -259,8 +259,7 @@ > saProps = new Properties(); > URL url = null; > try { > - url = VM.class.getClassLoader().getResource("sa.properties"); > - saProps.load(new BufferedInputStream(url.openStream())); > + saProps.load(VM.class.getResourceAsStream("/sa.properties")); > } catch (Exception e) { > System.err.println("Unable to load properties " + > (url == null ? "null" : > url.toString()) + This is a better version. Looks good. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Apr 23 16:44:06 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 23 Apr 2015 19:44:06 +0300 Subject: RFR: 8078519 Can't run SA tools from a non-images build In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com> <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com> Message-ID: <55392156.9070505@oracle.com> Staffan, Looks good for me. -Dmitry On 2015-04-23 17:51, Staffan Larsen wrote: > Here is an improved and simplified patch: > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -259,8 +259,7 @@ > saProps = new Properties(); > URL url = null; > try { > - url = VM.class.getClassLoader().getResource("sa.properties"); > - saProps.load(new BufferedInputStream(url.openStream())); > + saProps.load(VM.class.getResourceAsStream("/sa.properties")); > } catch (Exception e) { > System.err.println("Unable to load properties " + > (url == null ? "null" : url.toString()) + > > >> On 23 apr 2015, at 16:13, Staffan Larsen > > wrote: >> >> Please see description of the problem in the bug >> report: https://bugs.openjdk.java.net/browse/JDK-8078519 >> >> The simple fix is included below. >> >> Thanks, >> /Staffan >> >> >> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java >> b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java >> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java >> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java >> @@ -259,7 +259,12 @@ >> saProps = new Properties(); >> URL url = null; >> try { >> - url = VM.class.getClassLoader().getResource("sa.properties"); >> + if (VM.class.getClassLoader() == null) { >> + url = ClassLoader.getSystemResource("sa.properties"); >> + } >> + else { >> + url = VM.class.getClassLoader().getResource("sa.properties"); >> + } >> saProps.load(new BufferedInputStream(url.openStream())); >> } catch (Exception e) { >> System.err.println("Unable to load properties " + > -- 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 Apr 23 19:52:42 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Apr 2015 12:52:42 -0700 Subject: RFR: 8076473 Remove the jhat code and update makefiles In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> Message-ID: <55394D8A.4080101@oracle.com> It looks good. A question: Do we want to get rid of the jhat in the jdk/closed/old-build/common/Release.gmk ? jhat.1 \ com/sun/tools/hat \ jhat$(EXE_SUFFIX) Thanks, Serguei On 4/23/15 5:06 AM, Staffan Larsen wrote: > Please review this change to remove the jhat tool. I will not push > this change until the tests have been removed (see a different review > thread). > > JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 > bug: https://bugs.openjdk.java.net/browse/JDK-8076473 > > webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ > > webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ > > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Apr 23 21:50:04 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Apr 2015 14:50:04 -0700 Subject: RFR: 8076473 Remove the jhat code and update makefiles In-Reply-To: <55394D8A.4080101@oracle.com> References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> <55394D8A.4080101@oracle.com> Message-ID: <5539690C.4090007@oracle.com> No, that file is old legacy and not used anymore. It will hopefully soon go away. /Erik On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote: > It looks good. > A question: > Do we want to get rid of the jhat in the > jdk/closed/old-build/common/Release.gmk ? > jhat.1 \ > com/sun/tools/hat \ > jhat$(EXE_SUFFIX) > > Thanks, > Serguei > > > > On 4/23/15 5:06 AM, Staffan Larsen wrote: >> Please review this change to remove the jhat tool. I will not push >> this change until the tests have been removed (see a different review >> thread). >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 >> bug: https://bugs.openjdk.java.net/browse/JDK-8076473 >> >> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ >> >> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ >> >> >> Thanks, >> /Staffan >> > From serguei.spitsyn at oracle.com Thu Apr 23 23:41:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Apr 2015 16:41:35 -0700 Subject: RFR: 8076473 Remove the jhat code and update makefiles In-Reply-To: <5539690C.4090007@oracle.com> References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com> <55394D8A.4080101@oracle.com> <5539690C.4090007@oracle.com> Message-ID: <5539832F.2070900@oracle.com> On 4/23/15 2:50 PM, Erik Joelsson wrote: > No, that file is old legacy and not used anymore. It will hopefully > soon go away. Ok then. Thanks, Erik! Serguei > > /Erik > > On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote: >> It looks good. >> A question: >> Do we want to get rid of the jhat in the >> jdk/closed/old-build/common/Release.gmk ? >> jhat.1 \ >> com/sun/tools/hat \ >> jhat$(EXE_SUFFIX) >> >> Thanks, >> Serguei >> >> >> >> On 4/23/15 5:06 AM, Staffan Larsen wrote: >>> Please review this change to remove the jhat tool. I will not push >>> this change until the tests have been removed (see a different >>> review thread). >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473 >>> >>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ >>> >>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ >>> >>> >>> Thanks, >>> /Staffan >>> >> > From joe.darcy at oracle.com Fri Apr 24 01:54:17 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Apr 2015 18:54:17 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553703BC.1070504@oracle.com> References: <553703BC.1070504@oracle.com> Message-ID: <5539A249.7050105@oracle.com> Hello, Any additional comments on marking with tests in question with a "randomness" keyword? Thanks, -Joe On 4/21/2015 7:13 PM, Joseph D. Darcy wrote: > Hello, > > As the next step of implementing "Proposed new policies for JDK 9 > regression tests: tiered testing, intermittent failures, and > randomness" [1], please review this changeset which adds a > "randomness" jtreg keyword and tags 240 regression tests in the jdk > repository with the keyword: > > JDK-8078334: Mark regression tests using randomness > http://cr.openjdk.java.net/~darcy/8078334.0/ > > The update to test/TEST.ROOT is > > -# The list of keywords supported in the entire test suite > -keys=2d dnd i18n intermittent > +# The list of keywords supported in the entire test suite. The > +# "intermittent" keyword marks tests known to fail intermittently. > +# The "randomness" keyword marks tests using randomness with test > +# cases differing from run to run. (A test using a fixed random seed > +# would not count as "randomness" by this definition.) Extra care > +# should be taken to handle test failures of intermittent or > +# randomness tests. > + > +keys=2d dnd i18n intermittent randomness > > To find the affected files for this fix, I grepped over the regression > tests looking for "random" and verified if a random number generated > was used in a way where its values would differ from run to run. In > particular, as noted above, a java.util.Random random number generator > with a fixed seed did *not* qualify a test for the "randomness" keyword. > > The usual update to the files in this changeset is just > > + * @key randomness > > The updated tests are mostly in the core libs and security libs areas > with a few serviceability tests too. The list in this bug is not quite > exhaustive; I did not include rmi tests or client libraries tests. > > I verified that running > > jtreg ... -l -k:randomness . > > returns the expected number of tests and that the tests continue to > pass (or be ignored) when run. > > One goal of marking the tests using randomness is to help root out > some remaining intermittent test failures. If one of the randomness > tests is observed to fail intermittently, if it has not already been > updated to print out the random seed and be able to accept a > particular seed when run, the test should be so modified so that > future failures can log the seed value in hopes of reproducing the > failure. > > Brian Burkhalter has proactively made these sorts of changes to the > java.math tests earlier in JDK 9. [2] Since most of the randomness > tests don't have a history of instability (and due to the unexpected > large number of them!), I don't think it is necessary to proactively > update all the other tests without evidence of a history of failure. > However, when an otherwise unexplained failure is seen, I recommend > applying the sort of updates Brian has done in java.math to the > failing test(s). > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > > [2] JDK-8074460, Always print seeds used in [Splittable]Random > instances in java.math tests, > https://bugs.openjdk.java.net/browse/JDK-8074460 From Alan.Bateman at oracle.com Fri Apr 24 05:58:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Apr 2015 06:58:09 +0100 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <5539A249.7050105@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> Message-ID: <5539DB71.2070605@oracle.com> On 24/04/2015 02:54, Joseph D. Darcy wrote: > Hello, > > Any additional comments on marking with tests in question with a > "randomness" keyword? > > Thanks, > > -Joe > I don't object to this keyword although I should say that most of the (apparent) randomness that I've seen hasn't been because of tests using Random but rather because of non-deterministic sequence of tests running in the same VM. The switch from othervm to agentvm a few years ago took a long time to weed out issues, same thing (even more) with -concurrency. Another source of apparent randomness is just having a large pool of machines and where machines are randomly selected to execute the tests. I agree with your comments that tests using Random should have report the seed and a have a way to re-run with the same value. It could help with some cases. One thing that isn't clear to me is how this keyword will be maintained. If I modify a test and replace the use of Random then I guess I need to remember to also remove this label. When I add a test that uses Random ... Just wondering if there is a tool to do the tests analysis, identify the use of specific APIs ,and help identify where the keyword might be missing or not needed. -Alan. From yekaterina.kantserova at oracle.com Fri Apr 24 09:34:38 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 24 Apr 2015 11:34:38 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> Message-ID: <553A0E2E.4090805@oracle.com> Hi, Here comes the updated version. bug: https://bugs.openjdk.java.net/browse/JDK-8059047 webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: 70 /* 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore 72 * failures about resolving constantPoolOop fields using a negative lookahead 73 */ 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. Thanks, Katja On 04/22/2015 03:09 PM, Staffan Larsen wrote: > On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: > >>>>> > >>>>>Hi, > >>>>> > >>>>>Could I please have a review of this fix. > >>>>> > >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 > >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ > >>>>> > >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. > >>>>> > >>>>>The old jhat packages have been moved as follows: > >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model > >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser > >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util > >>>>> > >>>>>The source has not been changed except Copyrights year. > >>>>> > >>>>>Thanks, > >>>>>Katja From staffan.larsen at oracle.com Fri Apr 24 10:10:45 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Apr 2015 12:10:45 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <553A0E2E.4090805@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> Message-ID: > On 24 apr 2015, at 11:34, Yekaterina Kantserova wrote: > > Hi, > > Here comes the updated version. > > bug: https://bugs.openjdk.java.net/browse/JDK-8059047 > > webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ > webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it. Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it. > webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ test/serviceability/dcmd/gc/HeapDumpTest.java: Same thing: call delete() instead of deleteOnExit(). > > > One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: > > 70 /* > 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore > 72 * failures about resolving constantPoolOop fields using a negative lookahead > 73 */ > 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); > > It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. > > I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser? /Staffan > > > Thanks, > Katja > > > > On 04/22/2015 03:09 PM, Staffan Larsen wrote: >> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote: >> >>>>> >> >>>>>Hi, >> >>>>> >> >>>>>Could I please have a review of this fix. >> >>>>> >> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >> >>>>> >> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >> >>>>> >> >>>>>The old jhat packages have been moved as follows: >> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >> >>>>> >> >>>>>The source has not been changed except Copyrights year. >> >>>>> >> >>>>>Thanks, >> >>>>>Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Apr 24 10:23:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 24 Apr 2015 12:23:05 +0200 Subject: RFR 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java failed with AssertionError Message-ID: <553A1989.9010909@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8076971 Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00 The tests trying to access target JVMs via eg. 'jcmd' will fail on embedded configurations if the flag '-XX:+UsePerfData' is not specified. This patch adds this flag to the test application test builders thus making the target JVMs visible to 'jcmd'. Thanks, -JB- From staffan.larsen at oracle.com Fri Apr 24 10:44:11 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Apr 2015 12:44:11 +0200 Subject: RFR 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java failed with AssertionError In-Reply-To: <553A1989.9010909@oracle.com> References: <553A1989.9010909@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 24 apr 2015, at 12:23, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8076971 > Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00 > > The tests trying to access target JVMs via eg. 'jcmd' will fail on embedded configurations if the flag '-XX:+UsePerfData' is not specified. > > This patch adds this flag to the test application test builders thus making the target JVMs visible to 'jcmd'. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Fri Apr 24 11:28:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 24 Apr 2015 13:28:05 +0200 Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts Message-ID: <553A28C5.70409@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8077402 Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00 Currently, the test waits for 5*{timeout.factor} seconds for the target application to start up before timing out. On extremely slow machines even the timeout.factor will not assure a successful target application startup and the test will fail sporadically. The proposed solution is to defer timing-out to the test harness. The test library will still take care of collecting the thread dump and terminating any left-over processes (ProcessTools.startProcess() methods). While this will not remedy the failures on extremely slow machines it is better not to introduce any additional arbitrary time-out limits. As a part of this patch there is a small clarification in the javadoc of ProcessTools.startProcess() method and a null check in JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message. Thanks, -JB- From staffan.larsen at oracle.com Fri Apr 24 11:38:19 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Apr 2015 13:38:19 +0200 Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts In-Reply-To: <553A28C5.70409@oracle.com> References: <553A28C5.70409@oracle.com> Message-ID: <08C16F8F-92E5-4C9C-8AB6-D1DA1B03FF94@oracle.com> I think this looks good. jtreg is not very good at cleaning up processes that are launched by a test since there are no APIs in Java to find these processes. However, such APIs are being added as part of JEP 102 and once present, jtreg will make use of them to try to clean up better. /Staffan > On 24 apr 2015, at 13:28, Jaroslav Bachorik wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8077402 > Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00 > > Currently, the test waits for 5*{timeout.factor} seconds for the target application to start up before timing out. On extremely slow machines even the timeout.factor will not assure a successful target application startup and the test will fail sporadically. > > The proposed solution is to defer timing-out to the test harness. The test library will still take care of collecting the thread dump and terminating any left-over processes (ProcessTools.startProcess() methods). While this will not remedy the failures on extremely slow machines it is better not to introduce any additional arbitrary time-out limits. > > As a part of this patch there is a small clarification in the javadoc of ProcessTools.startProcess() method and a null check in JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message. > > Thanks, > > -JB- From yekaterina.kantserova at oracle.com Fri Apr 24 14:17:41 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 24 Apr 2015 16:17:41 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> Message-ID: <553A5085.10805@oracle.com> All suggestions have been implemented. Please find new webrevs here: webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 // Katja On 04/24/2015 12:10 PM, Staffan Larsen wrote: > >> On 24 apr 2015, at 11:34, Yekaterina Kantserova >> > > wrote: >> >> Hi, >> >> Here comes the updated version. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >> >> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >> >> webrev jdk: >> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >> > > test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: > > In main() I think you should change the deleteOnExit() to just > delete(). There is no reason to wait with it. > > Perhaps we should also verify that the file does not already exists > before we try to write to it. If it exists, we can delete it. > > > >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >> > > test/serviceability/dcmd/gc/HeapDumpTest.java: > > Same thing: call delete() instead of deleteOnExit(). > > >> >> >> One comment about changes in hotspot part. The refactored version of >> serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >> >> 70 /* >> 71 * Some hprof dumps of all objects contain >> constantPoolOop references that cannot be resolved, so we ignore >> 72 * failures about resolving constantPoolOop fields >> using a negative lookahead >> 73 */ >> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to >> resolve object.*constantPoolOop.*).*"); >> >> It depends on that the current version of jdk.test.lib.hprof parser >> simply write down warnings to stdout. As a result the test needs to >> invent own logic to parse it. >> >> I suggest instead to improve jdk.test.lib.hprof parser as a separate >> RFE. The parser will collect such information and provide a new >> method for getting it, e.g. >> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The >> serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly >> when RFE is implemented. > > Sounds right. A quick, hacky solution is to redirect System.out to a > stream or file while running the parser? > > /Staffan > >> >> >> Thanks, >> Katja >> >> >> >> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>> On 22 apr 2015, at 11:17, Yekaterina >>> Kantserova>> > wrote: >>> >>>>> >>> >>>>>Hi, >>> >>>>> >>> >>>>>Could I please have a review of this fix. >>> >>>>> >>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >>> >>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>> >>> >>>>> >>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool >>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put >>> parser/validator into common test library since the functionality >>> can be useful not only for SVC tools tests but even for some future >>> GC tests. >>> >>>>> >>> >>>>>The old jhat packages have been moved as follows: >>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>> >>>>> >>> >>>>>The source has not been changed except Copyrights year. >>> >>>>> >>> >>>>>Thanks, >>> >>>>>Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Fri Apr 24 14:33:59 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 24 Apr 2015 07:33:59 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi, Could I, please, have a review of this tests-only change: https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html The change renames com.oracle.java.testlibrary package to jdk.test.lib package: The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Everywhere in the hotspot/test files import statements have been changed as needed. Best regards, Alex From stefan.karlsson at oracle.com Fri Apr 24 14:41:38 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 24 Apr 2015 16:41:38 +0200 Subject: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES Message-ID: <553A5622.7040709@oracle.com> Hi, Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS. http://cr.openjdk.java.net/~stefank/8078601/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8078601 This code in thread.cpp is guarded by INCLUDE_ALL_GCS: #if INCLUDE_ALL_GCS // Dump concurrent locks ConcurrentLocksDump concurrent_locks; if (print_concurrent_locks) { concurrent_locks.dump_at_safepoint(); } #endif // INCLUDE_ALL_GCS but the code is not specific to any of our non-Serial GCs. The code should be guarded by INCLUDE_SERVICES. ConcurrentLocksDump::dump_at_safepoint() uses HeapInspection::find_instances_at_safepoint, which is declared in heapInspection.hpp: static void find_instances_at_safepoint(Klass* k, GrowableArray* result) NOT_SERVICES_RETURN; and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: make/excludeSrc.make: ifeq ($(INCLUDE_SERVICES), false) CXXFLAGS += -DINCLUDE_SERVICES=0 CFLAGS += -DINCLUDE_SERVICES=0 Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ attachListener_linux.cpp attachListener.cpp endif I've verified that this change builds with minimal1 and full HotSpot slowdebug build. Thanks, Stefank From staffan.larsen at oracle.com Fri Apr 24 15:08:31 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Apr 2015 17:08:31 +0200 Subject: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES In-Reply-To: <553A5622.7040709@oracle.com> References: <553A5622.7040709@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 24 apr 2015, at 16:41, Stefan Karlsson wrote: > > Hi, > > Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS. > > http://cr.openjdk.java.net/~stefank/8078601/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8078601 > > This code in thread.cpp is guarded by INCLUDE_ALL_GCS: > #if INCLUDE_ALL_GCS > // Dump concurrent locks > ConcurrentLocksDump concurrent_locks; > if (print_concurrent_locks) { > concurrent_locks.dump_at_safepoint(); > } > #endif // INCLUDE_ALL_GCS > > but the code is not specific to any of our non-Serial GCs. The code should be guarded by INCLUDE_SERVICES. > > ConcurrentLocksDump::dump_at_safepoint() uses HeapInspection::find_instances_at_safepoint, which is declared in heapInspection.hpp: > static void find_instances_at_safepoint(Klass* k, GrowableArray* result) NOT_SERVICES_RETURN; > > and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: make/excludeSrc.make: > > ifeq ($(INCLUDE_SERVICES), false) > CXXFLAGS += -DINCLUDE_SERVICES=0 > CFLAGS += -DINCLUDE_SERVICES=0 > > Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ > attachListener_linux.cpp attachListener.cpp > endif > > I've verified that this change builds with minimal1 and full HotSpot slowdebug build. > > Thanks, > Stefank From markus.gronlund at oracle.com Fri Apr 24 18:00:14 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 24 Apr 2015 11:00:14 -0700 (PDT) Subject: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES In-Reply-To: References: <553A5622.7040709@oracle.com> Message-ID: Looks good! Thanks Markus -----Original Message----- From: Staffan Larsen Sent: den 24 april 2015 11:09 To: Stefan Karlsson Cc: Serviceability Dev Subject: Re: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES Looks good! Thanks, /Staffan > On 24 apr 2015, at 16:41, Stefan Karlsson wrote: > > Hi, > > Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS. > > http://cr.openjdk.java.net/~stefank/8078601/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8078601 > > This code in thread.cpp is guarded by INCLUDE_ALL_GCS: > #if INCLUDE_ALL_GCS > // Dump concurrent locks > ConcurrentLocksDump concurrent_locks; if (print_concurrent_locks) { > concurrent_locks.dump_at_safepoint(); > } > #endif // INCLUDE_ALL_GCS > > but the code is not specific to any of our non-Serial GCs. The code should be guarded by INCLUDE_SERVICES. > > ConcurrentLocksDump::dump_at_safepoint() uses HeapInspection::find_instances_at_safepoint, which is declared in heapInspection.hpp: > static void find_instances_at_safepoint(Klass* k, GrowableArray* > result) NOT_SERVICES_RETURN; > > and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: make/excludeSrc.make: > > ifeq ($(INCLUDE_SERVICES), false) > CXXFLAGS += -DINCLUDE_SERVICES=0 > CFLAGS += -DINCLUDE_SERVICES=0 > > Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ > attachListener_linux.cpp attachListener.cpp endif > > I've verified that this change builds with minimal1 and full HotSpot slowdebug build. > > Thanks, > Stefank From joe.darcy at oracle.com Fri Apr 24 18:04:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 24 Apr 2015 11:04:24 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <5539DB71.2070605@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> Message-ID: <553A85A8.7080207@oracle.com> On 4/23/2015 10:58 PM, Alan Bateman wrote: > On 24/04/2015 02:54, Joseph D. Darcy wrote: >> Hello, >> >> Any additional comments on marking with tests in question with a >> "randomness" keyword? >> >> Thanks, >> >> -Joe >> > I don't object to this keyword although I should say that most of the > (apparent) randomness that I've seen hasn't been because of tests > using Random but rather because of non-deterministic sequence of tests > running in the same VM. The switch from othervm to agentvm a few years > ago took a long time to weed out issues, same thing (even more) with > -concurrency. Another source of apparent randomness is just having a > large pool of machines and where machines are randomly selected to > execute the tests. > > I agree with your comments that tests using Random should have report > the seed and a have a way to re-run with the same value. It could help > with some cases. > > One thing that isn't clear to me is how this keyword will be > maintained. If I modify a test and replace the use of Random then I > guess I need to remember to also remove this label. When I add a test > that uses Random ... Just wondering if there is a tool to do the > tests analysis, identify the use of specific APIs ,and help identify > where the keyword might be missing or not needed. > The goal of the keyword is to enable better analysis of bug failures. We (still) have some intermittent test failures in the platform, some probably remaining from -concurrency issues and some due to inconsistent machine config issues on the test farms. However, there is reason to believe some of the tests also fail because of the use of randomness in the generation of test cases. For example, the test java/lang/invoke/MethodHandles/CatchExceptionTest.java fails about once every three hundred runs when the random cases it generates trigger an error condition. Setting the seed to known-bad value causes the test to fail consistently (JDK-8055269). I have suspicions some of our other intermittently failing tests are in a similar but undiagnosed situation. If a test uses randomness, I think the default assumed cause for a test failure should switch from environmental causes (bad machine config, etc.) to the random behavior. Therefore, when a random-using test fails, I think the failure analysis needs to include recording of the bad seed to see if the failure is reproducible / deterministic with a fixed seed value. I was very surprised by the large number of random-using tests in the JDK regression tests. Nearly all of these have been stably passing for many years. After the one-time cost of this large update to add the keywords, there would be a small amount of incremental test maintenance as new random-using tests were added or the randomness value of a test changed. However, I would expect whether or not a test used randomness to be a property of a test that very rarely changed. Thanks, -Joe From david.holmes at oracle.com Fri Apr 24 21:49:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Apr 2015 07:49:04 +1000 Subject: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES In-Reply-To: <553A5622.7040709@oracle.com> References: <553A5622.7040709@oracle.com> Message-ID: <553ABA50.4020409@oracle.com> Looks good. Thanks Stefan. David On 25/04/2015 12:41 AM, Stefan Karlsson wrote: > Hi, > > Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS. > > http://cr.openjdk.java.net/~stefank/8078601/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8078601 > > This code in thread.cpp is guarded by INCLUDE_ALL_GCS: > #if INCLUDE_ALL_GCS > // Dump concurrent locks > ConcurrentLocksDump concurrent_locks; > if (print_concurrent_locks) { > concurrent_locks.dump_at_safepoint(); > } > #endif // INCLUDE_ALL_GCS > > but the code is not specific to any of our non-Serial GCs. The code > should be guarded by INCLUDE_SERVICES. > > ConcurrentLocksDump::dump_at_safepoint() uses > HeapInspection::find_instances_at_safepoint, which is declared in > heapInspection.hpp: > static void find_instances_at_safepoint(Klass* k, GrowableArray* > result) NOT_SERVICES_RETURN; > > and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: > make/excludeSrc.make: > > ifeq ($(INCLUDE_SERVICES), false) > CXXFLAGS += -DINCLUDE_SERVICES=0 > CFLAGS += -DINCLUDE_SERVICES=0 > > Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ > attachListener_linux.cpp attachListener.cpp > endif > > I've verified that this change builds with minimal1 and full HotSpot > slowdebug build. > > Thanks, > Stefank From david.holmes at oracle.com Mon Apr 27 00:17:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 10:17:14 +1000 Subject: RFR 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java failed with AssertionError In-Reply-To: <553A1989.9010909@oracle.com> References: <553A1989.9010909@oracle.com> Message-ID: <553D800A.3060702@oracle.com> Looks okay. Thanks, David On 24/04/2015 8:23 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8076971 > Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00 > > The tests trying to access target JVMs via eg. 'jcmd' will fail on > embedded configurations if the flag '-XX:+UsePerfData' is not specified. > > This patch adds this flag to the test application test builders thus > making the target JVMs visible to 'jcmd'. > > Thanks, > > -JB- From david.holmes at oracle.com Mon Apr 27 00:26:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 10:26:18 +1000 Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts In-Reply-To: <553A28C5.70409@oracle.com> References: <553A28C5.70409@oracle.com> Message-ID: <553D822A.6090303@oracle.com> Looks okay. Thanks, David On 24/04/2015 9:28 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8077402 > Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00 > > Currently, the test waits for 5*{timeout.factor} seconds for the target > application to start up before timing out. On extremely slow machines > even the timeout.factor will not assure a successful target application > startup and the test will fail sporadically. > > The proposed solution is to defer timing-out to the test harness. The > test library will still take care of collecting the thread dump and > terminating any left-over processes (ProcessTools.startProcess() > methods). While this will not remedy the failures on extremely slow > machines it is better not to introduce any additional arbitrary time-out > limits. > > As a part of this patch there is a small clarification in the javadoc of > ProcessTools.startProcess() method and a null check in > JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message. > > Thanks, > > -JB- From david.holmes at oracle.com Mon Apr 27 01:39:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2015 11:39:28 +1000 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: References: Message-ID: <553D9350.3060206@oracle.com> Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: I presume this is a first step towards fixing: https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Did you use "hg rename" for that? The webrev suggests not as it shows deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From stefan.karlsson at oracle.com Mon Apr 27 07:10:10 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Apr 2015 09:10:10 +0200 Subject: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES In-Reply-To: <553ABA50.4020409@oracle.com> References: <553A5622.7040709@oracle.com> <553ABA50.4020409@oracle.com> Message-ID: <553DE0D2.6010600@oracle.com> On 2015-04-24 23:49, David Holmes wrote: > Looks good. Thanks Stefan. Thanks, David. StefanK > > David > > On 25/04/2015 12:41 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to fix an incorrect usage of #if >> INCLUDE_ALL_GCS. >> >> http://cr.openjdk.java.net/~stefank/8078601/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8078601 >> >> This code in thread.cpp is guarded by INCLUDE_ALL_GCS: >> #if INCLUDE_ALL_GCS >> // Dump concurrent locks >> ConcurrentLocksDump concurrent_locks; >> if (print_concurrent_locks) { >> concurrent_locks.dump_at_safepoint(); >> } >> #endif // INCLUDE_ALL_GCS >> >> but the code is not specific to any of our non-Serial GCs. The code >> should be guarded by INCLUDE_SERVICES. >> >> ConcurrentLocksDump::dump_at_safepoint() uses >> HeapInspection::find_instances_at_safepoint, which is declared in >> heapInspection.hpp: >> static void find_instances_at_safepoint(Klass* k, GrowableArray* >> result) NOT_SERVICES_RETURN; >> >> and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: >> make/excludeSrc.make: >> >> ifeq ($(INCLUDE_SERVICES), false) >> CXXFLAGS += -DINCLUDE_SERVICES=0 >> CFLAGS += -DINCLUDE_SERVICES=0 >> >> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >> attachListener_linux.cpp attachListener.cpp >> endif >> >> I've verified that this change builds with minimal1 and full HotSpot >> slowdebug build. >> >> Thanks, >> Stefank From cheleswer.sahu at oracle.com Mon Apr 27 13:43:25 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Mon, 27 Apr 2015 19:13:25 +0530 Subject: [8u60] request for approval: 8072863: Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <553E1708.9090301@oracle.com> References: <553E1708.9090301@oracle.com> Message-ID: <553E3CFD.7070408@oracle.com> Hi! May I please have approval to backport this fix from JDK9 to JDK8. I have built the JDK-8 hotspot and tested already. JDK9 fix applies cleanly to JDK8. As I do not have an account for OPENJDK, David Buck will push the fix into jdk8u/hs-dev/hotspot. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072863 JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f47b463a95b8 Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-April/014392.html Regards, Cheleswer From coleen.phillimore at oracle.com Mon Apr 27 17:49:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Apr 2015 13:49:56 -0400 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <552832AF.8080204@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> Message-ID: <553E76C4.6090401@oracle.com> Serguei, This looks nice. I thought this change was going to delay calling AdjustCpoolCacheAndVtable until the end of the redefinition, rather than for each class, so was a bit confused by the change. Your change is a nice cleanup and improves MethodHandle method replacement performance. Your backport may not be simple for jdk8 because PreviousVersionNode is another type and not an InstanceKlass. Maybe you've convinced me that it's worth backporting those changes too. Let me know. Thanks, Coleen On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > This is the second class redefinition scalability/optimization fix > that is in my queue to push into 9 and 8u60. > > The approach is similar to the first one but much smaller. > For convenience, these are the links to the first scalability fix: > Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > Please, let me know if you have any chance to review this. > This is the last one that is waiting for your attention! :) > > Thanks, > Serguei > > On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8073705 >> >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >> >> >> >> Summary: >> >> This is the 2-nd round of performance/calability fixes in class >> redefinition. >> This time, the two remaining issues that were left alone in the >> first round fix: >> - optimized ConstantPoolCache::adjust_method_entries() is used >> for previous versions >> - the MemberNameTable::adjust_method_entries() has been >> optimized too >> - some cleanup >> >> >> Testing: >> In progress: nsk redefine classes tests, JTREG >> java/lang/instrument, com/sun/jdi >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Mon Apr 27 20:05:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 13:05:54 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E76C4.6090401@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> Message-ID: <553E96A2.3050000@oracle.com> Hi Coleen, Thank you for the review! On 4/27/15 10:49 AM, Coleen Phillimore wrote: > > Serguei, > > This looks nice. I thought this change was going to delay calling > AdjustCpoolCacheAndVtable until the end of the redefinition, rather > than for each class, so was a bit confused by the change. I consider this for as a next round of optimizations which is more risky. We need to decide when we are Ok to take this risk. My guess is that it is better to do it together with the constant pool merge elimination. > > Your change is a nice cleanup and improves MethodHandle method > replacement performance. Thanks! > > Your backport may not be simple for jdk8 because PreviousVersionNode > is another type and not an InstanceKlass. Maybe you've convinced me > that it's worth backporting those changes too. Let me know. I've already backported the first chunk where this problem was hit. It seems, this one should not be harder to backport. Thanks! Serguei > > Thanks, > Coleen > > On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen and Dan, >> >> This is the second class redefinition scalability/optimization fix >> that is in my queue to push into 9 and 8u60. >> >> The approach is similar to the first one but much smaller. >> For convenience, these are the links to the first scalability fix: >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> Please, let me know if you have any chance to review this. >> This is the last one that is waiting for your attention! :) >> >> Thanks, >> Serguei >> >> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>> >>> >>> Open hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>> >>> >>> >>> Summary: >>> >>> This is the 2-nd round of performance/calability fixes in class >>> redefinition. >>> This time, the two remaining issues that were left alone in the >>> first round fix: >>> - optimized ConstantPoolCache::adjust_method_entries() is used >>> for previous versions >>> - the MemberNameTable::adjust_method_entries() has been >>> optimized too >>> - some cleanup >>> >>> >>> Testing: >>> In progress: nsk redefine classes tests, JTREG >>> java/lang/instrument, com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Mon Apr 27 20:25:08 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 13:25:08 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E96A2.3050000@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> Message-ID: <553E9B24.3080809@oracle.com> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for the review! > > On 4/27/15 10:49 AM, Coleen Phillimore wrote: >> >> Serguei, >> >> This looks nice. I thought this change was going to delay calling >> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >> than for each class, so was a bit confused by the change. > > I consider this for as a next round of optimizations which is more risky. > We need to decide when we are Ok to take this risk. > My guess is that it is better to do it together with the constant pool > merge elimination. Sorry, I forgot to tell that my plan is to open another bug that should cover moving all this adjustments to the end of redefinition. This was a source of the confusion! Thanks, Serguei > >> >> Your change is a nice cleanup and improves MethodHandle method >> replacement performance. > > Thanks! > >> >> Your backport may not be simple for jdk8 because PreviousVersionNode >> is another type and not an InstanceKlass. Maybe you've convinced me >> that it's worth backporting those changes too. Let me know. > > I've already backported the first chunk where this problem was hit. > It seems, this one should not be harder to backport. > > Thanks! > Serguei > >> >> Thanks, >> Coleen >> >> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen and Dan, >>> >>> This is the second class redefinition scalability/optimization fix >>> that is in my queue to push into 9 and 8u60. >>> >>> The approach is similar to the first one but much smaller. >>> For convenience, these are the links to the first scalability fix: >>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>> >>> Please, let me know if you have any chance to review this. >>> This is the last one that is waiting for your attention! :) >>> >>> Thanks, >>> Serguei >>> >>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>> >>>> >>>> Open hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> This is the 2-nd round of performance/calability fixes in class >>>> redefinition. >>>> This time, the two remaining issues that were left alone in the >>>> first round fix: >>>> - optimized ConstantPoolCache::adjust_method_entries() is used >>>> for previous versions >>>> - the MemberNameTable::adjust_method_entries() has been >>>> optimized too >>>> - some cleanup >>>> >>>> >>>> Testing: >>>> In progress: nsk redefine classes tests, JTREG >>>> java/lang/instrument, com/sun/jdi >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From serguei.spitsyn at oracle.com Mon Apr 27 21:12:59 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 14:12:59 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception Message-ID: <553EA65B.6080805@oracle.com> Please, review the jdk 9 fix for: https://bugs.openjdk.java.net/browse/JDK-8076579 9 hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 Summary: This bug is a regression that was introduced but the fix of: https://bugs.openjdk.java.net/browse/JDK-7187554 The bug is in the InterpreterRuntime::member_name_arg_or_null() function that does not return NULL if there is no invokestatic appendix argument (MemberName). It is why the _remove_activation_preserving_args is trying to to restore unexisting appendix argument when a pop instruction is executed by a debugger in the debuggee VM. The fix is to correctly set NULL in the thread vm_result when it is necessary: thread->set_vm_result(NULL); Testing in progress: In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, JTREG com/sun/jdi tests, ad-hog ExceptionBug.java test from the bug report Thanks, Serguei From serguei.spitsyn at oracle.com Tue Apr 28 04:27:46 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2015 21:27:46 -0700 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553E9B24.3080809@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> <553E9B24.3080809@oracle.com> Message-ID: <553F0C42.4060000@oracle.com> On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote: > On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for the review! >> >> On 4/27/15 10:49 AM, Coleen Phillimore wrote: >>> >>> Serguei, >>> >>> This looks nice. I thought this change was going to delay calling >>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >>> than for each class, so was a bit confused by the change. >> >> I consider this for as a next round of optimizations which is more >> risky. >> We need to decide when we are Ok to take this risk. >> My guess is that it is better to do it together with the constant >> pool merge elimination. > > Sorry, I forgot to tell that my plan is to open another bug that should > cover moving all this adjustments to the end of redefinition. > This was a source of the confusion! I've filed a separate bug report for the above: https://bugs.openjdk.java.net/browse/JDK-8078725 Thanks, Serguei > > Thanks, > Serguei > >> >>> >>> Your change is a nice cleanup and improves MethodHandle method >>> replacement performance. >> >> Thanks! >> >>> >>> Your backport may not be simple for jdk8 because PreviousVersionNode >>> is another type and not an InstanceKlass. Maybe you've convinced me >>> that it's worth backporting those changes too. Let me know. >> >> I've already backported the first chunk where this problem was hit. >> It seems, this one should not be harder to backport. >> >> Thanks! >> Serguei >> >>> >>> Thanks, >>> Coleen >>> >>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen and Dan, >>>> >>>> This is the second class redefinition scalability/optimization fix >>>> that is in my queue to push into 9 and 8u60. >>>> >>>> The approach is similar to the first one but much smaller. >>>> For convenience, these are the links to the first scalability fix: >>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>>> >>>> Please, let me know if you have any chance to review this. >>>> This is the last one that is waiting for your attention! :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>> >>>>> >>>>> Open hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the 2-nd round of performance/calability fixes in class >>>>> redefinition. >>>>> This time, the two remaining issues that were left alone in the >>>>> first round fix: >>>>> - optimized ConstantPoolCache::adjust_method_entries() is >>>>> used for previous versions >>>>> - the MemberNameTable::adjust_method_entries() has been >>>>> optimized too >>>>> - some cleanup >>>>> >>>>> >>>>> Testing: >>>>> In progress: nsk redefine classes tests, JTREG >>>>> java/lang/instrument, com/sun/jdi >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Apr 28 06:17:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2015 16:17:15 +1000 Subject: [8u60] request for approval: 8072863: Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <553E3CFD.7070408@oracle.com> References: <553E1708.9090301@oracle.com> <553E3CFD.7070408@oracle.com> Message-ID: <553F25EB.6060807@oracle.com> Approved. Thanks, David On 27/04/2015 11:43 PM, cheleswer sahu wrote: > Hi! > > May I please have approval to backport this fix from JDK9 to JDK8. I > have built the JDK-8 hotspot and tested already. JDK9 fix applies > cleanly to JDK8. As I do not have an account for OPENJDK, David Buck > will push the fix into jdk8u/hs-dev/hotspot. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072863 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f47b463a95b8 > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-April/014392.html > > > Regards, > Cheleswer > > > > > > > > > > > > > > > > > From alexander.kulyakhtin at oracle.com Tue Apr 28 08:55:42 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 01:55:42 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi, Could someone, please, comment on the proposed renaming from com.oracle.java.testlibrary to jdk.test.lib in the hotspot repo? The changes have been verified by running all the hotspot tests and making sure there are no compilation or other errors related to the change. Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Friday, April 24, 2015 5:34:22 PM GMT +03:00 Iraq Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi, Could I, please, have a review of this tests-only change: https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html The change renames com.oracle.java.testlibrary package to jdk.test.lib package: The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, Everywhere in the hotspot/test files import statements have been changed as needed. Best regards, Alex From alexander.kulyakhtin at oracle.com Tue Apr 28 11:08:54 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 04:08:54 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi David, Thank you very much for your comments. > I presume this is a first step towards fixing: > https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? Yes, this is correct > Did you use "hg rename" for that? The webrev suggests not as it shows No, I used hg add and hg delete. I'm going to fix this now by doing hg rename > Copyright dates will need updating in many cases. I'm going to update the copyrights I'll send out the updated webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From staffan.larsen at oracle.com Tue Apr 28 12:05:43 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Apr 2015 14:05:43 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: <553A5085.10805@oracle.com> References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> <553A5085.10805@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 24 apr 2015, at 16:17, Yekaterina Kantserova wrote: > > All suggestions have been implemented. Please find new webrevs here: > > webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 > webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 > webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 > > // Katja > > > > On 04/24/2015 12:10 PM, Staffan Larsen wrote: >> >>> On 24 apr 2015, at 11:34, Yekaterina Kantserova > wrote: >>> >>> Hi, >>> >>> Here comes the updated version. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>> >>> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >>> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >> >> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: >> >> In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it. >> >> Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it. >> >> >> >>> webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >> >> test/serviceability/dcmd/gc/HeapDumpTest.java: >> >> Same thing: call delete() instead of deleteOnExit(). >> >> >>> >>> >>> One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >>> >>> 70 /* >>> 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore >>> 72 * failures about resolving constantPoolOop fields using a negative lookahead >>> 73 */ >>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*"); >>> >>> It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it. >>> >>> I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented. >> >> Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser? >> >> /Staffan >> >>> >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova> wrote: >>>> >>>>> >>>> >>>>>Hi, >>>> >>>>> >>>> >>>>>Could I please have a review of this fix. >>>> >>>>> >>>> >>>>>bug:https:// bugs.openjdk.java.net/browse/JDK-8059047 >>>> >>>>>webrev:http:// cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>> >>>>> >>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039 ). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests. >>>> >>>>> >>>> >>>>>The old jhat packages have been moved as follows: >>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>> >>>>> >>>> >>>>>The source has not been changed except Copyrights year. >>>> >>>>> >>>> >>>>>Thanks, >>>> >>>>>Katja >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Apr 28 12:11:38 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 28 Apr 2015 14:11:38 +0200 Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests In-Reply-To: References: <55376716.10806@oracle.com> <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com> <55379321.1090403@oracle.com> <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com> <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com> <553A0E2E.4090805@oracle.com> <553A5085.10805@oracle.com> Message-ID: <553F78FA.3090202@oracle.com> Staffan, Thanks for the review! // Katja On 04/28/2015 02:05 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 24 apr 2015, at 16:17, Yekaterina Kantserova >> > > wrote: >> >> All suggestions have been implemented. Please find new webrevs here: >> >> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02 >> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02 >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01 >> >> // Katja >> >> >> >> On 04/24/2015 12:10 PM, Staffan Larsen wrote: >>> >>>> On 24 apr 2015, at 11:34, Yekaterina Kantserova >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Here comes the updated version. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047 >>>> >>>> webrev root: >>>> http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/ >>>> >>>> webrev jdk: >>>> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/ >>>> >>> >>> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java: >>> >>> In main() I think you should change the deleteOnExit() to just >>> delete(). There is no reason to wait with it. >>> >>> Perhaps we should also verify that the file does not already exists >>> before we try to write to it. If it exists, we can delete it. >>> >>> >>> >>>> webrev hotspot: >>>> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/ >>>> >>> >>> test/serviceability/dcmd/gc/HeapDumpTest.java: >>> >>> Same thing: call delete() instead of deleteOnExit(). >>> >>> >>>> >>>> >>>> One comment about changes in hotspot part. The refactored version >>>> of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check: >>>> >>>> 70 /* >>>> 71 * Some hprof dumps of all objects contain >>>> constantPoolOop references that cannot be resolved, so we ignore >>>> 72 * failures about resolving constantPoolOop fields >>>> using a negative lookahead >>>> 73 */ >>>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to >>>> resolve object.*constantPoolOop.*).*"); >>>> >>>> It depends on that the current version of jdk.test.lib.hprof parser >>>> simply write down warnings to stdout. As a result the test needs to >>>> invent own logic to parse it. >>>> >>>> I suggest instead to improve jdk.test.lib.hprof parser as a >>>> separate RFE. The parser will collect such information and provide >>>> a new method for getting it, e.g. >>>> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The >>>> serviceability/dcmd/gc/HeapDumpTest.java will be changed >>>> accordingly when RFE is implemented. >>> >>> Sounds right. A quick, hacky solution is to redirect System.out to a >>> stream or file while running the parser? >>> >>> /Staffan >>> >>>> >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 04/22/2015 03:09 PM, Staffan Larsen wrote: >>>>> On 22 apr 2015, at 11:17, Yekaterina >>>>> Kantserova>>>> > wrote: >>>>> >>>>> >>>>> >>>>>Hi, >>>>> >>>>> >>>>> >>>>>Could I please have a review of this fix. >>>>> >>>>> >>>>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047 >>>>> >>>>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/ >>>>> >>>>> >>>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool >>>>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to >>>>> put parser/validator into common test library since the >>>>> functionality can be useful not only for SVC tools tests but even >>>>> for some future GC tests. >>>>> >>>>> >>>>> >>>>>The old jhat packages have been moved as follows: >>>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model >>>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser >>>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util >>>>> >>>>> >>>>> >>>>>The source has not been changed except Copyrights year. >>>>> >>>>> >>>>> >>>>>Thanks, >>>>> >>>>>Katja >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Tue Apr 28 13:09:43 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 06:09:43 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Hi, I've updated the webrev in accordance with David's comments. Could you, please, review the changes: > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html Best regards, Alex ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi David, Thank you very much for your comments. > I presume this is a first step towards fixing: > https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? Yes, this is correct > Did you use "hg rename" for that? The webrev suggests not as it shows No, I used hg add and hg delete. I'm going to fix this now by doing hg rename > Copyright dates will need updating in many cases. I'm going to update the copyrights I'll send out the updated webrev as soon as I'm done. Best regards, Alex ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Hi Alex, On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this tests-only change: > > https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package > Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html > > The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, deleted and added files rather than moved ones. > Everywhere in the hotspot/test files import statements have been changed as needed. Seems okay based on scanning through the patch. Copyright dates will need updating in many cases. Thanks, David > Best regards, > Alex > > > From coleen.phillimore at oracle.com Tue Apr 28 13:58:46 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Apr 2015 09:58:46 -0400 Subject: RFR (S) 8073705: more performance issues in class redefinition In-Reply-To: <553F0C42.4060000@oracle.com> References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com> <553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com> <553E9B24.3080809@oracle.com> <553F0C42.4060000@oracle.com> Message-ID: <553F9216.6080106@oracle.com> On 4/28/15, 12:27 AM, serguei.spitsyn at oracle.com wrote: > On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote: >> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Thank you for the review! >>> >>> On 4/27/15 10:49 AM, Coleen Phillimore wrote: >>>> >>>> Serguei, >>>> >>>> This looks nice. I thought this change was going to delay calling >>>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather >>>> than for each class, so was a bit confused by the change. >>> >>> I consider this for as a next round of optimizations which is more >>> risky. >>> We need to decide when we are Ok to take this risk. >>> My guess is that it is better to do it together with the constant >>> pool merge elimination. >> >> Sorry, I forgot to tell that my plan is to open another bug that should >> cover moving all this adjustments to the end of redefinition. >> This was a source of the confusion! > > I've filed a separate bug report for the above: > https://bugs.openjdk.java.net/browse/JDK-8078725 This is good. I'll watch this next bug. Yes, the optimizations are more risky here but I think they would still use the same code. But it definitely needs more testing. Coleen > > > Thanks, > Serguei > >> >> Thanks, >> Serguei >> >>> >>>> >>>> Your change is a nice cleanup and improves MethodHandle method >>>> replacement performance. >>> >>> Thanks! >>> >>>> >>>> Your backport may not be simple for jdk8 because >>>> PreviousVersionNode is another type and not an InstanceKlass. Maybe >>>> you've convinced me that it's worth backporting those changes too. >>>> Let me know. >>> >>> I've already backported the first chunk where this problem was hit. >>> It seems, this one should not be harder to backport. >>> >>> Thanks! >>> Serguei >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen and Dan, >>>>> >>>>> This is the second class redefinition scalability/optimization fix >>>>> that is in my queue to push into 9 and 8u60. >>>>> >>>>> The approach is similar to the first one but much smaller. >>>>> For convenience, these are the links to the first scalability fix: >>>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >>>>> >>>>> Please, let me know if you have any chance to review this. >>>>> This is the last one that is waiting for your attention! :) >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8073705 >>>>>> >>>>>> >>>>>> Open hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the 2-nd round of performance/calability fixes in >>>>>> class redefinition. >>>>>> This time, the two remaining issues that were left alone in >>>>>> the first round fix: >>>>>> - optimized ConstantPoolCache::adjust_method_entries() is >>>>>> used for previous versions >>>>>> - the MemberNameTable::adjust_method_entries() has been >>>>>> optimized too >>>>>> - some cleanup >>>>>> >>>>>> >>>>>> Testing: >>>>>> In progress: nsk redefine classes tests, JTREG >>>>>> java/lang/instrument, com/sun/jdi >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Tue Apr 28 15:09:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Apr 2015 17:09:53 +0200 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Message-ID: Looks good! Thanks, /Staffan > On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote: > > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html > > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From alexander.kulyakhtin at oracle.com Tue Apr 28 15:39:26 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 28 Apr 2015 08:39:26 -0700 (PDT) Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Message-ID: Hi Staffan, Thank you very much for the reviewing. Best regards, Alex ----- Original Message ----- From: staffan.larsen at oracle.com To: alexander.kulyakhtin at oracle.com Cc: david.holmes at oracle.com, hotspot-dev at openjdk.java.net, serviceability-dev at openjdk.java.net Sent: Tuesday, April 28, 2015 6:09:55 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package Looks good! Thanks, /Staffan > On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote: > > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html > > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From aph at redhat.com Tue Apr 28 18:27:22 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Apr 2015 19:27:22 +0100 Subject: sun/jvm/hotspot/oops/Symbol.java Message-ID: <553FD10A.7020006@redhat.com> I've been testing serviceability support for AArch64, and I keep getting bad pointers and NullPointerExceptions. I thought it was a bug in my back-end, but it's not. The problem is that we read a Symbol pointer out of the constant pool and then try to use it. Unfortunately, the bottom two bits of a symbol pointer in the constant pool have special meanings and we must mask them before use. This is my fix: diff -r 11b7f6b12521 agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java --- a/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Fri Apr 24 16:28:29 2015 +0100 +++ b/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Tue Apr 28 19:23:18 2015 +0100 @@ -43,6 +43,8 @@ }); } + static class TagBits { final static int _resolved_value = 0, _symbol_bit = 1, _pseudo_bit = 2, _symbol_mask = 3; } + private static synchronized void initialize(TypeDataBase db) throws WrongTypeException { Type type = db.lookupType("Symbol"); length = type.getCIntegerField("_length"); @@ -60,7 +62,8 @@ if (addr == null) { return null; } - return new Symbol(addr); + return new Symbol(addr.andWithMask(~ TagBits._symbol_mask)); } I'm not at all sure this is the right place to fix it, but it works. I'm just really surprised no-one noticed this before. Andrew. From dmitry.samersoff at oracle.com Tue Apr 28 20:00:36 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Apr 2015 23:00:36 +0300 Subject: sun/jvm/hotspot/oops/Symbol.java In-Reply-To: <553FD10A.7020006@redhat.com> References: <553FD10A.7020006@redhat.com> Message-ID: <553FE6E4.5010502@oracle.com> Andrew, Thank you for the fix, I'll take a look at it -Dmitry (current SA owner) On 2015-04-28 21:27, Andrew Haley wrote: > I've been testing serviceability support for AArch64, and I keep getting > bad pointers and NullPointerExceptions. > > I thought it was a bug in my back-end, but it's not. The problem is > that we read a Symbol pointer out of the constant pool and then try to > use it. Unfortunately, the bottom two bits of a symbol pointer in the > constant pool have special meanings and we must mask them before use. > > This is my fix: > > diff -r 11b7f6b12521 agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java > --- a/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Fri Apr 24 16:28:29 2015 +0100 > +++ b/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Tue Apr 28 19:23:18 2015 +0100 > @@ -43,6 +43,8 @@ > }); > } > > + static class TagBits { final static int _resolved_value = 0, _symbol_bit = 1, _pseudo_bit = 2, _symbol_mask = 3; } > + > private static synchronized void initialize(TypeDataBase db) throws WrongTypeException { > Type type = db.lookupType("Symbol"); > length = type.getCIntegerField("_length"); > @@ -60,7 +62,8 @@ > if (addr == null) { > return null; > } > - return new Symbol(addr); > + return new Symbol(addr.andWithMask(~ TagBits._symbol_mask)); > } > > I'm not at all sure this is the right place to fix it, but it works. > > I'm just really surprised no-one noticed this before. > > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From joe.darcy at oracle.com Tue Apr 28 23:53:41 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 28 Apr 2015 16:53:41 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553A85A8.7080207@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> <553A85A8.7080207@oracle.com> Message-ID: <55401D85.1090306@oracle.com> Hello, I'd like to get this changeset, or something close to it, pushed soon so we can start taking advantage of better failure triaging. Any further concerns? Thanks, -Joe On 4/24/2015 11:04 AM, joe darcy wrote: > On 4/23/2015 10:58 PM, Alan Bateman wrote: >> On 24/04/2015 02:54, Joseph D. Darcy wrote: >>> Hello, >>> >>> Any additional comments on marking with tests in question with a >>> "randomness" keyword? >>> >>> Thanks, >>> >>> -Joe >>> >> I don't object to this keyword although I should say that most of the >> (apparent) randomness that I've seen hasn't been because of tests >> using Random but rather because of non-deterministic sequence of >> tests running in the same VM. The switch from othervm to agentvm a >> few years ago took a long time to weed out issues, same thing (even >> more) with -concurrency. Another source of apparent randomness is >> just having a large pool of machines and where machines are randomly >> selected to execute the tests. >> >> I agree with your comments that tests using Random should have report >> the seed and a have a way to re-run with the same value. It could >> help with some cases. >> >> One thing that isn't clear to me is how this keyword will be >> maintained. If I modify a test and replace the use of Random then I >> guess I need to remember to also remove this label. When I add a test >> that uses Random ... Just wondering if there is a tool to do the >> tests analysis, identify the use of specific APIs ,and help identify >> where the keyword might be missing or not needed. >> > > The goal of the keyword is to enable better analysis of bug failures. > We (still) have some intermittent test failures in the platform, some > probably remaining from -concurrency issues and some due to > inconsistent machine config issues on the test farms. However, there > is reason to believe some of the tests also fail because of the use of > randomness in the generation of test cases. For example, the test > > java/lang/invoke/MethodHandles/CatchExceptionTest.java > > fails about once every three hundred runs when the random cases it > generates trigger an error condition. Setting the seed to known-bad > value causes the test to fail consistently (JDK-8055269). I have > suspicions some of our other intermittently failing tests are in a > similar but undiagnosed situation. > > If a test uses randomness, I think the default assumed cause for a > test failure should switch from environmental causes (bad machine > config, etc.) to the random behavior. Therefore, when a random-using > test fails, I think the failure analysis needs to include recording of > the bad seed to see if the failure is reproducible / deterministic > with a fixed seed value. > > I was very surprised by the large number of random-using tests in the > JDK regression tests. Nearly all of these have been stably passing for > many years. After the one-time cost of this large update to add the > keywords, there would be a small amount of incremental test > maintenance as new random-using tests were added or the randomness > value of a test changed. However, I would expect whether or not a test > used randomness to be a property of a test that very rarely changed. > > Thanks, > > -Joe From Alan.Bateman at oracle.com Wed Apr 29 06:51:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Apr 2015 07:51:18 +0100 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55401D85.1090306@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> <553A85A8.7080207@oracle.com> <55401D85.1090306@oracle.com> Message-ID: <55407F66.1030905@oracle.com> On 29/04/2015 00:53, Joseph D. Darcy wrote: > Hello, > > I'd like to get this changeset, or something close to it, pushed soon > so we can start taking advantage of better failure triaging. > > Any further concerns? I should have been clearer, I don't have any issues with the proposed patch. I was mostly probing to see how the keyword would be used as it looks to be more for triage rather than test selection. -Alan From aph at redhat.com Wed Apr 29 07:42:33 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Apr 2015 08:42:33 +0100 Subject: RFR: 8078521: AARCH64: Add AArch64 SA support In-Reply-To: <553A8B20.9050109@oracle.com> References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com> <553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com> Message-ID: <55408B69.8050108@redhat.com> On 04/24/2015 07:27 PM, Dean Long wrote: > Not a review, but a couple things I noticed: > > agent/src/os/linux/ps_proc.c: > > I don't think you need to change this file. There is already > PTRACE_GETREGSET support there. > > > > agent/src/os/linux/Makefile: > > + echo FECK > > The conflict will be handled in a separate bug (8078632). http://cr.openjdk.java.net/~aph/8078521-2/ Andrew. From serguei.spitsyn at oracle.com Wed Apr 29 09:48:43 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2015 02:48:43 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <553EA65B.6080805@oracle.com> References: <553EA65B.6080805@oracle.com> Message-ID: <5540A8FB.4010101@oracle.com> Ping... Just wanted to tell that it is a very safe and simple one-liner so that I assumed it to be reviewed in a couple of days, not weeks! :) Thanks! Serguei On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8076579 > > > 9 hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 > > > > Summary: > > This bug is a regression that was introduced but the fix of: > https://bugs.openjdk.java.net/browse/JDK-7187554 > > The bug is in the InterpreterRuntime::member_name_arg_or_null() > function that > does not return NULL if there is no invokestatic appendix argument > (MemberName). > It is why the _remove_activation_preserving_args is trying to to > restore unexisting > appendix argument when a pop instruction is executed by a debugger > in the debuggee VM. > The fix is to correctly set NULL in the thread vm_result when it is > necessary: > thread->set_vm_result(NULL); > > > Testing in progress: > In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, > JTREG com/sun/jdi tests, > ad-hog ExceptionBug.java test from the bug report > > > Thanks, > Serguei From jaroslav.bachorik at oracle.com Wed Apr 29 10:02:33 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Apr 2015 12:02:33 +0200 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <5540A8FB.4010101@oracle.com> References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> Message-ID: <5540AC39.9030900@oracle.com> The fix looks ok as far as the change goes. I'm relying on your analysis for the correctness. -JB- On 29.4.2015 11:48, serguei.spitsyn at oracle.com wrote: > Ping... > Just wanted to tell that it is a very safe and simple one-liner so that > I assumed it to be reviewed in a couple of days, not weeks! :) > > Thanks! > Serguei > > On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8076579 >> >> >> 9 hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >> >> >> >> Summary: >> >> This bug is a regression that was introduced but the fix of: >> https://bugs.openjdk.java.net/browse/JDK-7187554 >> >> The bug is in the InterpreterRuntime::member_name_arg_or_null() >> function that >> does not return NULL if there is no invokestatic appendix argument >> (MemberName). >> It is why the _remove_activation_preserving_args is trying to to >> restore unexisting >> appendix argument when a pop instruction is executed by a debugger >> in the debuggee VM. >> The fix is to correctly set NULL in the thread vm_result when it is >> necessary: >> thread->set_vm_result(NULL); >> >> >> Testing in progress: >> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, >> JTREG com/sun/jdi tests, >> ad-hog ExceptionBug.java test from the bug report >> >> >> Thanks, >> Serguei > From david.holmes at oracle.com Wed Apr 29 11:23:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Apr 2015 21:23:00 +1000 Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default> Message-ID: <5540BF14.1070606@oracle.com> On 28/04/2015 11:09 PM, Alexander Kulyakhtin wrote: > Hi, > > I've updated the webrev in accordance with David's comments. > > Could you, please, review the changes: > >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html Looks good. Aside: test/compiler/c2/8005956/PolynomialRoot.java doesn't have an OpenJDK copyright header. (Added by JDK-8017510) Thanks, David > Best regards, > Alex > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi David, > > Thank you very much for your comments. > >> I presume this is a first step towards fixing: >> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ? > Yes, this is correct > >> Did you use "hg rename" for that? The webrev suggests not as it shows > No, I used hg add and hg delete. > I'm going to fix this now by doing hg rename > >> Copyright dates will need updating in many cases. > I'm going to update the copyrights > > I'll send out the updated webrev as soon as I'm done. > > Best regards, > Alex > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package > > Hi Alex, > > On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this tests-only change: >> >> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package >> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html >> >> The change renames com.oracle.java.testlibrary package to jdk.test.lib package: > > > >> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming, > > deleted and added files rather than moved ones. > >> Everywhere in the hotspot/test files import statements have been changed as needed. > > Seems okay based on scanning through the patch. > > Copyright dates will need updating in many cases. > > Thanks, > David > >> Best regards, >> Alex >> >> >> From serguei.spitsyn at oracle.com Wed Apr 29 11:49:00 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2015 04:49:00 -0700 Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception In-Reply-To: <5540AC39.9030900@oracle.com> References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com> <5540AC39.9030900@oracle.com> Message-ID: <5540C52C.1080003@oracle.com> Thank you a lot, Jaroslav! Serguei On 4/29/15 3:02 AM, Jaroslav Bachorik wrote: > The fix looks ok as far as the change goes. > > I'm relying on your analysis for the correctness. > > -JB- > > On 29.4.2015 11:48, serguei.spitsyn at oracle.com wrote: >> Ping... >> Just wanted to tell that it is a very safe and simple one-liner so that >> I assumed it to be reviewed in a couple of days, not weeks! :) >> >> Thanks! >> Serguei >> >> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 9 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8076579 >>> >>> >>> 9 hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1 >>> >>> >>> >>> >>> Summary: >>> >>> This bug is a regression that was introduced but the fix of: >>> https://bugs.openjdk.java.net/browse/JDK-7187554 >>> >>> The bug is in the InterpreterRuntime::member_name_arg_or_null() >>> function that >>> does not return NULL if there is no invokestatic appendix argument >>> (MemberName). >>> It is why the _remove_activation_preserving_args is trying to to >>> restore unexisting >>> appendix argument when a pop instruction is executed by a debugger >>> in the debuggee VM. >>> The fix is to correctly set NULL in the thread vm_result when it is >>> necessary: >>> thread->set_vm_result(NULL); >>> >>> >>> Testing in progress: >>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, >>> JTREG com/sun/jdi tests, >>> ad-hog ExceptionBug.java test from the bug report >>> >>> >>> Thanks, >>> Serguei >> > From alexander.kulyakhtin at oracle.com Wed Apr 29 14:33:41 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 29 Apr 2015 07:33:41 -0700 (PDT) Subject: RFR: JDK-8078962: Add Open JDK copyright to PolynomialRoot.java test Message-ID: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default> Hi, Could you, please, review the copyright change in the file below? There's no code changes, only the copyright has been changed. CR: https://bugs.openjdk.java.net/browse/JDK-8078962 Add Open JDK copyright to PolynomialRoot.java test Webrev: http://cr.openjdk.java.net/~akulyakh/8078962/webrev00/ Best regards, Alexander From jaroslav.bachorik at oracle.com Wed Apr 29 17:47:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Apr 2015 19:47:16 +0200 Subject: RFR: JDK-8078962: Add Open JDK copyright to PolynomialRoot.java test In-Reply-To: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default> References: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default> Message-ID: <55411924.9090703@oracle.com> Looks good! -JB- On 29.4.2015 16:33, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the copyright change in the file below? > There's no code changes, only the copyright has been changed. > > CR: https://bugs.openjdk.java.net/browse/JDK-8078962 Add Open JDK copyright to PolynomialRoot.java test > Webrev: http://cr.openjdk.java.net/~akulyakh/8078962/webrev00/ > > Best regards, > Alexander > From yekaterina.kantserova at oracle.com Thu Apr 30 07:39:10 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 30 Apr 2015 09:39:10 +0200 Subject: RFR(XXS): 8079120: serviceability/dcmd/gc/HeapDumpAllTest.java: compilation failed Message-ID: <5541DC1E.8000509@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8079120 webrev: http://cr.openjdk.java.net/~ykantser/8079120/webrev.00/ Thanks, Katja From staffan.larsen at oracle.com Thu Apr 30 07:49:18 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Apr 2015 09:49:18 +0200 Subject: RFR(XXS): 8079120: serviceability/dcmd/gc/HeapDumpAllTest.java: compilation failed In-Reply-To: <5541DC1E.8000509@oracle.com> References: <5541DC1E.8000509@oracle.com> Message-ID: <4DB0D766-D54B-4D5B-B330-F626068F57AF@oracle.com> Looks good! Thanks, /Staffan > On 30 apr 2015, at 09:39, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8079120 > webrev: http://cr.openjdk.java.net/~ykantser/8079120/webrev.00/ > > Thanks, > Katja > > > From jaroslav.bachorik at oracle.com Thu Apr 30 14:25:57 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 30 Apr 2015 16:25:57 +0200 Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently Message-ID: <55423B75.6000703@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8078143 Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00 The test fails intermittently due to inconsistent reporting of the live threads number.It is related to https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, caused by) - certain performance counters used for the thread accounting are being updated under a mutex but are read without it - and it can lead to stale data being reported. More details are available in the linked issue and discussion. Because of this it is not enough to join() a terminating thread to make sure the numbers would be correct. Luckily enough, it seems to be sufficient to wait for a short time before actually accessing the counters to be able to get a consistent view. In this fix I opted for a ridiculously huge interval of 500ms just to be sure. Thanks, -JB- From jaroslav.bachorik at oracle.com Thu Apr 30 14:48:06 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 30 Apr 2015 16:48:06 +0200 Subject: RFR 8072906: sun/management/jmxremote/bootstrap/CustomLauncherTest.java failing on embedded platform Message-ID: <554240A6.7070309@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8072906 Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00 The test tries to exercise a custom launcher on embedded platforms and fails because the corresponding binary is not available. The test should not require the presence of the binary and skip the execution gracefully if it can't find one - this was broken while addressing JDK-8029809. The fix brings back the ability just skip the test if the launcher binary does not exist. Thanks, -JB- From martinrb at google.com Thu Apr 30 17:18:36 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 30 Apr 2015 10:18:36 -0700 Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently In-Reply-To: <55423B75.6000703@oracle.com> References: <55423B75.6000703@oracle.com> Message-ID: Tests that sleep can almost always be better written some other way. In this case, I would prefer busy-waiting with timeout until the expected condition becomes true. Here's some code from jsr166 tck tests: /** * Spin-waits until sync.isQueued(t) becomes true. */ void waitForQueuedThread(AbstractQueuedSynchronizer sync, Thread t) { long startTime = System.nanoTime(); while (!sync.isQueued(t)) { if (millisElapsedSince(startTime) > LONG_DELAY_MS) throw new AssertionFailedError("timed out"); Thread.yield(); } assertTrue(t.isAlive()); } On Thu, Apr 30, 2015 at 7:25 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8078143 > Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00 > > The test fails intermittently due to inconsistent reporting of the live > threads number.It is related to > https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, caused > by) - certain performance counters used for the thread accounting are being > updated under a mutex but are read without it - and it can lead to stale > data being reported. More details are available in the linked issue and > discussion. > > Because of this it is not enough to join() a terminating thread to make > sure the numbers would be correct. Luckily enough, it seems to be > sufficient to wait for a short time before actually accessing the counters > to be able to get a consistent view. In this fix I opted for a ridiculously > huge interval of 500ms just to be sure. > > Thanks, > > -JB- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Apr 30 18:27:23 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 30 Apr 2015 20:27:23 +0200 Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently In-Reply-To: References: <55423B75.6000703@oracle.com> Message-ID: <5542740B.6080507@oracle.com> On 30.4.2015 19:18, Martin Buchholz wrote: > Tests that sleep can almost always be better written some other way. > In this case, I would prefer busy-waiting with timeout until the > expected condition becomes true. The thing is that in case of a real issue with the thread counters we a/ would be busy-waiting till the test times out (using an arbitrary delay is also problematic due to different performance of different machines running with different configurations) b/ would get a rather confusing message about the test timing out at the end -JB- > > Here's some code from jsr166 tck tests: > > /** > * Spin-waits until sync.isQueued(t) becomes true. > */ > void waitForQueuedThread(AbstractQueuedSynchronizer sync, Thread t) { > long startTime = System.nanoTime(); > while (!sync.isQueued(t)) { > if (millisElapsedSince(startTime) > LONG_DELAY_MS) > throw new AssertionFailedError("timed out"); > Thread.yield(); > } > assertTrue(t.isAlive()); > } > > > On Thu, Apr 30, 2015 at 7:25 AM, Jaroslav Bachorik > > wrote: > > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8078143 > Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00 > > The test fails intermittently due to inconsistent reporting of the > live threads number.It is related to > https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, > caused by) - certain performance counters used for the thread > accounting are being updated under a mutex but are read without it - > and it can lead to stale data being reported. More details are > available in the linked issue and discussion. > > Because of this it is not enough to join() a terminating thread to > make sure the numbers would be correct. Luckily enough, it seems to > be sufficient to wait for a short time before actually accessing the > counters to be able to get a consistent view. In this fix I opted > for a ridiculously huge interval of 500ms just to be sure. > > Thanks, > > -JB- > > From david.holmes at oracle.com Thu Apr 30 21:08:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 May 2015 07:08:18 +1000 Subject: RFR 8072906: sun/management/jmxremote/bootstrap/CustomLauncherTest.java failing on embedded platform In-Reply-To: <554240A6.7070309@oracle.com> References: <554240A6.7070309@oracle.com> Message-ID: <554299C2.6040301@oracle.com> On 1/05/2015 12:48 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8072906 > Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00 > > The test tries to exercise a custom launcher on embedded platforms and > fails because the corresponding binary is not available. The test should > not require the presence of the binary and skip the execution gracefully > if it can't find one - this was broken while addressing JDK-8029809. > > The fix brings back the ability just skip the test if the launcher > binary does not exist. A message to that effect would be useful. Thanks, David > Thanks, > > -JB- From serguei.spitsyn at oracle.com Thu Apr 30 22:20:53 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Apr 2015 15:20:53 -0700 Subject: RFR 8072906: sun/management/jmxremote/bootstrap/CustomLauncherTest.java failing on embedded platform In-Reply-To: <554299C2.6040301@oracle.com> References: <554240A6.7070309@oracle.com> <554299C2.6040301@oracle.com> Message-ID: <5542AAC5.1040906@oracle.com> +1 for the suggestion from David. Otherwise, the fix looks Ok. No need to re-review after printing a message is added. Thanks, Serguei On 4/30/15 2:08 PM, David Holmes wrote: > On 1/05/2015 12:48 AM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8072906 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00 >> >> The test tries to exercise a custom launcher on embedded platforms and >> fails because the corresponding binary is not available. The test should >> not require the presence of the binary and skip the execution gracefully >> if it can't find one - this was broken while addressing JDK-8029809. >> >> The fix brings back the ability just skip the test if the launcher >> binary does not exist. > > A message to that effect would be useful. > > Thanks, > David > >> Thanks, >> >> -JB- From david.holmes at oracle.com Thu Apr 30 23:56:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 May 2015 09:56:25 +1000 Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently In-Reply-To: <55423B75.6000703@oracle.com> References: <55423B75.6000703@oracle.com> Message-ID: <5542C129.1070600@oracle.com> Hi Jaroslav, On 1/05/2015 12:25 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8078143 > Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00 > > The test fails intermittently due to inconsistent reporting of the live > threads number.It is related to > https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, > caused by) - certain performance counters used for the thread accounting > are being updated under a mutex but are read without it - and it can > lead to stale data being reported. More details are available in the > linked issue and discussion. Okay I just refreshed my memory on that - the fix is non-trivial unfortunately. > Because of this it is not enough to join() a terminating thread to make > sure the numbers would be correct. Right. > Luckily enough, it seems to be > sufficient to wait for a short time before actually accessing the > counters to be able to get a consistent view. In this fix I opted for a > ridiculously huge interval of 500ms just to be sure. It is a kludge but there's little else to be done without fixing 8021335. So grudgingly Reviewed. Thanks, David > Thanks, > > -JB-