From staffan.larsen at oracle.com Tue Jul 1 06:05:24 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 08:05:24 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B191E4.9030304@oracle.com> References: <53B191E4.9030304@oracle.com> Message-ID: Jaroslav, I wonder about this snippet: 167 ti1 = mbean.getThreadInfo(tid); 168 testBlocked(ti, () -> mbean.getThreadInfo(tid), lockName, lock1); 169 ti = ti1; When ti is used later (line 177) it may not have the values of the ThreadInfo that was actually ok:ed by testBlocked() (since testBlocked() loops). Is this a problem? Thanks, /Staffan On 30 jun 2014, at 18:35, Jaroslav Bachorik wrote: > Please, review this test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 > Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 > > The problem described in this issue is that while a thread was blocked the blocked count reported by the MBean does not reflect it in very rare cases. However, it should be enough to wait a few moments to let the VM counter propagate the value to the MBean. > > The attempted fix will cause the test to wait for the expected values instead of doing a one-time check. In the worst case the test will be timed out by the harness. > > The rest of the changes just add more info to debug outputs. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Jul 1 08:48:44 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 10:48:44 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: References: <53B191E4.9030304@oracle.com> Message-ID: <53B275EC.1020006@oracle.com> On 07/01/2014 08:05 AM, Staffan Larsen wrote: > Jaroslav, > > I wonder about this snippet: > > 167 ti1 = mbean.getThreadInfo(tid); > 168 testBlocked(ti, () -> mbean.getThreadInfo(tid), lockName, lock1); > 169 ti = ti1; > > When ti is used later (line 177) it may not have the values of the ThreadInfo that was actually ok:ed by testBlocked() (since testBlocked() loops). Is this a problem? In this case it would probably make no difference since we are checking only for the reported number of thread blocked events being increased. But using the actual up-to-date ThreadInfo makes the intentions clear and does not change the test outcome. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.01 -JB- > > Thanks, > /Staffan > > > > On 30 jun 2014, at 18:35, Jaroslav Bachorik wrote: > >> Please, review this test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 >> >> The problem described in this issue is that while a thread was blocked the blocked count reported by the MBean does not reflect it in very rare cases. However, it should be enough to wait a few moments to let the VM counter propagate the value to the MBean. >> >> The attempted fix will cause the test to wait for the expected values instead of doing a one-time check. In the worst case the test will be timed out by the harness. >> >> The rest of the changes just add more info to debug outputs. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Tue Jul 1 08:55:44 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 10:55:44 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B275EC.1020006@oracle.com> References: <53B191E4.9030304@oracle.com> <53B275EC.1020006@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 1 jul 2014, at 10:48, Jaroslav Bachorik wrote: > On 07/01/2014 08:05 AM, Staffan Larsen wrote: >> Jaroslav, >> >> I wonder about this snippet: >> >> 167 ti1 = mbean.getThreadInfo(tid); >> 168 testBlocked(ti, () -> mbean.getThreadInfo(tid), lockName, lock1); >> 169 ti = ti1; >> >> When ti is used later (line 177) it may not have the values of the ThreadInfo that was actually ok:ed by testBlocked() (since testBlocked() loops). Is this a problem? > > In this case it would probably make no difference since we are checking only for the reported number of thread blocked events being increased. > > But using the actual up-to-date ThreadInfo makes the intentions clear and does not change the test outcome. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.01 > > -JB- > >> >> Thanks, >> /Staffan >> >> >> >> On 30 jun 2014, at 18:35, Jaroslav Bachorik wrote: >> >>> Please, review this test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 >>> >>> The problem described in this issue is that while a thread was blocked the blocked count reported by the MBean does not reflect it in very rare cases. However, it should be enough to wait a few moments to let the VM counter propagate the value to the MBean. >>> >>> The attempted fix will cause the test to wait for the expected values instead of doing a one-time check. In the worst case the test will be timed out by the harness. >>> >>> The rest of the changes just add more info to debug outputs. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Tue Jul 1 14:56:52 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 16:56:52 +0200 Subject: jmx-dev RFR 8044427: [test] sun/management/jmxremote/startstop/JMXStartStopTest times out intermittently on Solaris/Sparcv9 Message-ID: <53B2CC34.3030007@oracle.com> Please, review this simple test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8044427 Webrev: http://cr.openjdk.java.net/~jbachorik/8044427/webrev.00 The test fails intermittently on Solaris 10 / Sparcv9 with timeout signalled after 480s. The investigation shows that the Sparcv9 Solaris test machines are particularly slow when starting a JVM. This test starts up a new JVM 13 times and when the system is otherwise busy the test can not be finished in 480s. The proposed fix is to increase the test timeout due to the intensive JVM process creation. The increased timeout does not affect the regular test runs - there are no endless loops relying on the harness to interrupt them. Thanks, -JB- From staffan.larsen at oracle.com Tue Jul 1 15:21:24 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 17:21:24 +0200 Subject: jmx-dev RFR 8044427: [test] sun/management/jmxremote/startstop/JMXStartStopTest times out intermittently on Solaris/Sparcv9 In-Reply-To: <53B2CC34.3030007@oracle.com> References: <53B2CC34.3030007@oracle.com> Message-ID: <6EAFC39A-CE08-49A0-9578-14211D2A3BEC@oracle.com> Looks good! Thanks, /Staffan On 1 jul 2014, at 16:56, Jaroslav Bachorik wrote: > Please, review this simple test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8044427 > Webrev: http://cr.openjdk.java.net/~jbachorik/8044427/webrev.00 > > The test fails intermittently on Solaris 10 / Sparcv9 with timeout signalled after 480s. The investigation shows that the Sparcv9 Solaris test machines are particularly slow when starting a JVM. This test starts up a new JVM 13 times and when the system is otherwise busy the test can not be finished in 480s. > > The proposed fix is to increase the test timeout due to the intensive JVM process creation. The increased timeout does not affect the regular test runs - there are no endless loops relying on the harness to interrupt them. > > Thanks, > > -JB- From shanliang.jiang at oracle.com Tue Jul 1 19:20:31 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 01 Jul 2014 21:20:31 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B191E4.9030304@oracle.com> References: <53B191E4.9030304@oracle.com> Message-ID: <53B309FF.6060904@oracle.com> So the issue (race cases) is from the implementation and detected by the test, it meant that the thread info could be incorrect in some cases, and your fix is to ask the test to try again in this case. What is the real cause? if it is not worth or impossible to fix, should we give a warning in the ThreadMXBean Javadoc? or for some reason this could be ignored? I am looking at JDK-8048215 and thinking that it might be same issue. Shanliang Jaroslav Bachorik wrote: > Please, review this test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 > Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 > > The problem described in this issue is that while a thread was blocked > the blocked count reported by the MBean does not reflect it in very > rare cases. However, it should be enough to wait a few moments to let > the VM counter propagate the value to the MBean. > > The attempted fix will cause the test to wait for the expected values > instead of doing a one-time check. In the worst case the test will be > timed out by the harness. > > The rest of the changes just add more info to debug outputs. > > Thanks, > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 1 20:49:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 22:49:34 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B309FF.6060904@oracle.com> References: <53B191E4.9030304@oracle.com> <53B309FF.6060904@oracle.com> Message-ID: <53B31EDE.7050705@oracle.com> On 07/01/2014 09:20 PM, shanliang wrote: > So the issue (race cases) is from the implementation and detected by the > test, it meant that the thread info could be incorrect in some cases, > and your fix is to ask the test to try again in this case. Yes. That should give the counters time to propagate. > > What is the real cause? if it is not worth or impossible to fix, should > we give a warning in the ThreadMXBean Javadoc? or for some reason this > could be ignored? If you check the hotspot sources you would see that the various thread related counters are not updated under any lock (probably the performance would suffer greatly). Therefore, in very rare cases you could get stale data in ThreadInfo. > > I am looking at JDK-8048215 > and thinking that it > might be same issue. With the lock info it might be even more complicated. Any synchronization primitives you use in the test may influence the results - I was burned pretty badly by Phaser and CyclicBarrier in such tests ... -JB- > > Shanliang > > > Jaroslav Bachorik wrote: >> Please, review this test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 >> >> The problem described in this issue is that while a thread was blocked >> the blocked count reported by the MBean does not reflect it in very >> rare cases. However, it should be enough to wait a few moments to let >> the VM counter propagate the value to the MBean. >> >> The attempted fix will cause the test to wait for the expected values >> instead of doing a one-time check. In the worst case the test will be >> timed out by the harness. >> >> The rest of the changes just add more info to debug outputs. >> >> Thanks, >> >> -JB- > From shanliang.jiang at oracle.com Tue Jul 1 21:01:48 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 01 Jul 2014 23:01:48 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B31EDE.7050705@oracle.com> References: <53B191E4.9030304@oracle.com> <53B309FF.6060904@oracle.com> <53B31EDE.7050705@oracle.com> Message-ID: <53B321BC.2090905@oracle.com> Jaroslav Bachorik wrote: > On 07/01/2014 09:20 PM, shanliang wrote: >> So the issue (race cases) is from the implementation and detected by the >> test, it meant that the thread info could be incorrect in some cases, >> and your fix is to ask the test to try again in this case. > > Yes. That should give the counters time to propagate. > >> >> What is the real cause? if it is not worth or impossible to fix, should >> we give a warning in the ThreadMXBean Javadoc? or for some reason this >> could be ignored? > > If you check the hotspot sources you would see that the various thread > related counters are not updated under any lock (probably the > performance would suffer greatly). Therefore, in very rare cases you > could get stale data in ThreadInfo. So it is possible but very rare for a user to get incorrect info, and seems impossible to fix it, my questions were "should we give a warning in the ThreadMXBean Javadoc, or for some reason this could be ignored?" I can understand the difficulty, just thought that it might be helpful to give user some info. > >> >> I am looking at JDK-8048215 >> and thinking that it >> might be same issue. > > With the lock info it might be even more complicated. Any > synchronization primitives you use in the test may influence the > results - I was burned pretty badly by Phaser and CyclicBarrier in > such tests ... If difficult to fix in the implementation, then re-try is a way to make the test pass. Shanliang > > -JB- > >> >> Shanliang >> >> >> Jaroslav Bachorik wrote: >>> Please, review this test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 >>> >>> The problem described in this issue is that while a thread was blocked >>> the blocked count reported by the MBean does not reflect it in very >>> rare cases. However, it should be enough to wait a few moments to let >>> the VM counter propagate the value to the MBean. >>> >>> The attempted fix will cause the test to wait for the expected values >>> instead of doing a one-time check. In the worst case the test will be >>> timed out by the harness. >>> >>> The rest of the changes just add more info to debug outputs. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Wed Jul 2 07:52:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Jul 2014 09:52:04 +0200 Subject: jmx-dev RFR 8038794: java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <53B321BC.2090905@oracle.com> References: <53B191E4.9030304@oracle.com> <53B309FF.6060904@oracle.com> <53B31EDE.7050705@oracle.com> <53B321BC.2090905@oracle.com> Message-ID: <53B3BA24.5050209@oracle.com> On 07/01/2014 11:01 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 07/01/2014 09:20 PM, shanliang wrote: >>> So the issue (race cases) is from the implementation and detected by the >>> test, it meant that the thread info could be incorrect in some cases, >>> and your fix is to ask the test to try again in this case. >> >> Yes. That should give the counters time to propagate. >> >>> >>> What is the real cause? if it is not worth or impossible to fix, should >>> we give a warning in the ThreadMXBean Javadoc? or for some reason this >>> could be ignored? >> >> If you check the hotspot sources you would see that the various thread >> related counters are not updated under any lock (probably the >> performance would suffer greatly). Therefore, in very rare cases you >> could get stale data in ThreadInfo. > So it is possible but very rare for a user to get incorrect info, and > seems impossible to fix it, my questions were "should we give a warning > in the ThreadMXBean Javadoc, or for some reason this could be ignored?" > I can understand the difficulty, just thought that it might be helpful > to give user some info. Yes, I see your point. Unless you are trying to use ThreadInfo for some hand-crafted synchronization you shouldn't hit this issue. But let's check what the ThreadInfo doc says about the reliability of the provided data. >> >>> >>> I am looking at JDK-8048215 >>> and thinking that it >>> might be same issue. >> >> With the lock info it might be even more complicated. Any >> synchronization primitives you use in the test may influence the >> results - I was burned pretty badly by Phaser and CyclicBarrier in >> such tests ... > If difficult to fix in the implementation, then re-try is a way to make > the test pass. Unfortunately yes. We had to do more compromises when testing the results provided by ThreadInfo since we were hitting the principle of uncertainty in the JVM world :( -JB- > > Shanliang >> >> -JB- >> >>> >>> Shanliang >>> >>> >>> Jaroslav Bachorik wrote: >>>> Please, review this test fix. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8038794/webrev.00 >>>> >>>> The problem described in this issue is that while a thread was blocked >>>> the blocked count reported by the MBean does not reflect it in very >>>> rare cases. However, it should be enough to wait a few moments to let >>>> the VM counter propagate the value to the MBean. >>>> >>>> The attempted fix will cause the test to wait for the expected values >>>> instead of doing a one-time check. In the worst case the test will be >>>> timed out by the harness. >>>> >>>> The rest of the changes just add more info to debug outputs. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From otaviopolianasantana at gmail.com Fri Jul 11 01:36:03 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 10 Jul 2014 22:36:03 -0300 Subject: jmx-dev RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8049892 http://cr.openjdk.java.net/~prr/8049892/ -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Fri Jul 11 06:41:14 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 11 Jul 2014 08:41:14 +0200 Subject: jmx-dev RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: Message-ID: Hi Ot?vio, changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. Please exclude following classes from the patch: src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java And please exclude following classes from the patch too: src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java This classes will be fixed by the patch for the issue 5043030. Otherwise it looks good. Best regards, Andrej Golovnin On Fri, Jul 11, 2014 at 3:36 AM, Ot?vio Gon?alves de Santana < otaviopolianasantana at gmail.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8049892 > http://cr.openjdk.java.net/~prr/8049892/ > > -- > Cheers!. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava * > 55 (11) 98255-3513 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 29 13:47:51 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Jul 2014 15:47:51 +0200 Subject: jmx-dev RFR 8052961: Test "com/sun/tools/attach/StartManagementAgent.java" failing intermittently Message-ID: <53D7A607.5030500@oracle.com> Please, review this (hopefully last) change to StartManagementAgent test Issue : https://bugs.openjdk.java.net/browse/JDK-8052961 Webrev: http://cr.openjdk.java.net/~jbachorik/8052961/webrev.00 The test needs a properly registered service for the ServiceLoader - but it fails to compile the provider class explicitly leading to intermittent failures. The fix is to add the "SimpleProvider" to "@run build ..." line. Thanks, -JB-