From shanliang.jiang at oracle.com Mon Dec 1 13:50:16 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 01 Dec 2014 14:50:16 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs Message-ID: <547C7218.2040001@oracle.com> Hi, please review this test bug fix: webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8065764 The test tested the mode "difference", according to the Javadoc: If the counter difference mode is used, the value of the derived gauge is calculated as the difference between the observed counter values for two successive observations. The test set the first value and then waited 2 times of granularityperiod at line 171, hoped that the monitor would get the first observation during this waiting time, but the test could fail because granularityperiod * 2 was not enough and the test did the second set before the monitor did the first observation. It is easy to make the test timeout by commenting out the line 171. The proposed solution is to get informed when the monitor did observation on calling: StdObservedObject.getNbObjects(); Thanks, Shanliang From daniel.fuchs at oracle.com Mon Dec 1 14:29:38 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 01 Dec 2014 15:29:38 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547C7218.2040001@oracle.com> References: <547C7218.2040001@oracle.com> Message-ID: <547C7B52.3060501@oracle.com> 55 // derived gange 56 private volatile int derivedGange = 1; Typo in both lines: gange -> gauge - data = new Integer(values[i]); - echo(">>> Set data = " + data.intValue()); It is strange that you no longer have to set the value to a different value. I don't understand how the test can succeed: first gauge: data.intValue() - 0 = data.intValue() = 0 second gauge (and so on): data.intValue() - data.intValue() = 0 how can that ever exceed the threshold of 2? I must have missed something. best regards -- daniel On 01/12/14 14:50, shanliang wrote: > Hi, > please review this test bug fix: > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8065764 > > The test tested the mode "difference", according to the Javadoc: > If the counter difference mode is used, the value of the derived > gauge is calculated as the difference between the observed counter > values for two successive observations. > > The test set the first value and then waited 2 times of > granularityperiod at line 171, hoped that the monitor would get the > first observation during this waiting time, but the test could fail > because granularityperiod * 2 was not enough and the test did the second > set before the monitor did the first observation. > > It is easy to make the test timeout by commenting out the line 171. > > The proposed solution is to get informed when the monitor did > observation on calling: > StdObservedObject.getNbObjects(); > > Thanks, > Shanliang > > From jaroslav.bachorik at oracle.com Mon Dec 1 14:49:02 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 01 Dec 2014 15:49:02 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547C7218.2040001@oracle.com> References: <547C7218.2040001@oracle.com> Message-ID: <547C7FDE.5020808@oracle.com> On 12/01/2014 02:50 PM, shanliang wrote: > Hi, > please review this test bug fix: > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8065764 > test/javax/management/monitor/CounterMonitorTest.java L61 - observedValue could be Integer L225-238 - you could replace this block with the usage of Phaser (if you'd do that you could completely remove 'observedValue') -JB- > The test tested the mode "difference", according to the Javadoc: > If the counter difference mode is used, the value of the derived > gauge is calculated as the difference between the observed counter > values for two successive observations. > > The test set the first value and then waited 2 times of > granularityperiod at line 171, hoped that the monitor would get the > first observation during this waiting time, but the test could fail > because granularityperiod * 2 was not enough and the test did the second > set before the monitor did the first observation. > > It is easy to make the test timeout by commenting out the line 171. > > The proposed solution is to get informed when the monitor did > observation on calling: > StdObservedObject.getNbObjects(); > > Thanks, > Shanliang > > From jaroslav.bachorik at oracle.com Mon Dec 1 14:55:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 01 Dec 2014 15:55:09 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547C7B52.3060501@oracle.com> References: <547C7218.2040001@oracle.com> <547C7B52.3060501@oracle.com> Message-ID: <547C814D.6010909@oracle.com> On 12/01/2014 03:29 PM, Daniel Fuchs wrote: > > 55 // derived gange > 56 private volatile int derivedGange = 1; > > Typo in both lines: gange -> gauge > > - data = new Integer(values[i]); > - echo(">>> Set data = " + data.intValue()); > > > It is strange that you no longer have to set the value to a > different value. > > I don't understand how the test can succeed: > > first gauge: > data.intValue() - 0 = data.intValue() = 0 > > second gauge (and so on): > data.intValue() - data.intValue() = 0 > > how can that ever exceed the threshold of 2? L27 in the new version reads - 'data = new Integer(data.intValue() + derivedGange);' where 'derivedGange' gets incremented in each pass before actually hitting L27. Therefore the sequence of values would be: 1. 2 2. 5 3. 9 4. 14 5. 20 6. 27 7. 35 8. 44 9. 54 Each time the increment is higher than the threshold. -JB- > > I must have missed something. > > best regards > > -- daniel > > > On 01/12/14 14:50, shanliang wrote: >> Hi, >> please review this test bug fix: >> >> webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8065764 >> >> The test tested the mode "difference", according to the Javadoc: >> If the counter difference mode is used, the value of the derived >> gauge is calculated as the difference between the observed counter >> values for two successive observations. >> >> The test set the first value and then waited 2 times of >> granularityperiod at line 171, hoped that the monitor would get the >> first observation during this waiting time, but the test could fail >> because granularityperiod * 2 was not enough and the test did the second >> set before the monitor did the first observation. >> >> It is easy to make the test timeout by commenting out the line 171. >> >> The proposed solution is to get informed when the monitor did >> observation on calling: >> StdObservedObject.getNbObjects(); >> >> Thanks, >> Shanliang >> >> > From shanliang.jiang at oracle.com Tue Dec 2 13:40:29 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 02 Dec 2014 14:40:29 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547C7FDE.5020808@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> Message-ID: <547DC14D.1070308@oracle.com> Jaroslav Bachorik wrote: > On 12/01/2014 02:50 PM, shanliang wrote: >> Hi, >> please review this test bug fix: >> >> webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8065764 >> > > test/javax/management/monitor/CounterMonitorTest.java > L61 - observedValue could be Integer Could be, but not make difference, observedValue is only used with the operation "==", like while (value != observedValue) > L225-238 - you could replace this block with the usage of Phaser (if > you'd do that you could completely remove 'observedValue') Not sure that it is a good idea to remove "observedValue" by using Phaser, yes using Phaser can tell when the monitor does an observation, but it is better to know which count value the monitor observed, in case the thread was waked up accidentally. Thanks, Shanliang > > -JB- > > >> The test tested the mode "difference", according to the Javadoc: >> If the counter difference mode is used, the value of the derived >> gauge is calculated as the difference between the observed counter >> values for two successive observations. >> >> The test set the first value and then waited 2 times of >> granularityperiod at line 171, hoped that the monitor would get the >> first observation during this waiting time, but the test could fail >> because granularityperiod * 2 was not enough and the test did the second >> set before the monitor did the first observation. >> >> It is easy to make the test timeout by commenting out the line 171. >> >> The proposed solution is to get informed when the monitor did >> observation on calling: >> StdObservedObject.getNbObjects(); >> >> Thanks, >> Shanliang >> >> > From jaroslav.bachorik at oracle.com Tue Dec 2 14:57:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 15:57:40 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DC14D.1070308@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> Message-ID: <547DD364.7080100@oracle.com> On 12/02/2014 02:40 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 12/01/2014 02:50 PM, shanliang wrote: >>> Hi, >>> please review this test bug fix: >>> >>> webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>> >> >> test/javax/management/monitor/CounterMonitorTest.java >> L61 - observedValue could be Integer > Could be, but not make difference, observedValue is only used with the > operation "==", like > while (value != observedValue) In that case having a correct type would make even more sense for the readability. >> L225-238 - you could replace this block with the usage of Phaser (if >> you'd do that you could completely remove 'observedValue') > Not sure that it is a good idea to remove "observedValue" by using > Phaser, yes using Phaser can tell when the monitor does an observation, > but it is better to know which count value the monitor observed, in case > the thread was waked up accidentally. I don't think phaser can be confused by spurious wake-ups. If you want to keep the current way of synchronizing then you should make the 'count' variable volatile (L77) - it might be read and written to from different threads. -JB- > > Thanks, > Shanliang >> >> -JB- >> >> >>> The test tested the mode "difference", according to the Javadoc: >>> If the counter difference mode is used, the value of the derived >>> gauge is calculated as the difference between the observed counter >>> values for two successive observations. >>> >>> The test set the first value and then waited 2 times of >>> granularityperiod at line 171, hoped that the monitor would get the >>> first observation during this waiting time, but the test could fail >>> because granularityperiod * 2 was not enough and the test did the second >>> set before the monitor did the first observation. >>> >>> It is easy to make the test timeout by commenting out the line 171. >>> >>> The proposed solution is to get informed when the monitor did >>> observation on calling: >>> StdObservedObject.getNbObjects(); >>> >>> Thanks, >>> Shanliang >>> >>> >> > From shanliang.jiang at oracle.com Tue Dec 2 15:22:17 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 02 Dec 2014 16:22:17 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DD364.7080100@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> Message-ID: <547DD929.2000401@oracle.com> Jaroslav Bachorik wrote: > On 12/02/2014 02:40 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 12/01/2014 02:50 PM, shanliang wrote: >>>> Hi, >>>> please review this test bug fix: >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>> >>> >>> test/javax/management/monitor/CounterMonitorTest.java >>> L61 - observedValue could be Integer >> Could be, but not make difference, observedValue is only used with the >> operation "==", like >> while (value != observedValue) > > In that case having a correct type would make even more sense for the > readability. Agree in general:) but the variable "count" is declared as "Object" in StdObservedObject, and "observedValue" is used to save observed "count" value, so better to keep the same type for "more readability"? and avoid a casting when setting "observedValue" > >>> L225-238 - you could replace this block with the usage of Phaser (if >>> you'd do that you could completely remove 'observedValue') >> Not sure that it is a good idea to remove "observedValue" by using >> Phaser, yes using Phaser can tell when the monitor does an observation, >> but it is better to know which count value the monitor observed, in case >> the thread was waked up accidentally. > > I don't think phaser can be confused by spurious wake-ups. > > If you want to keep the current way of synchronizing then you should > make the 'count' variable volatile (L77) - it might be read and > written to from different threads. Phaser should not make a false wakeup, but use "observedValue" can make sure that the observation happens on the right "count" value. Yes "count" should be declared as "volatile". Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ Thanks, Shanliang > > -JB- > >> >> Thanks, >> Shanliang >>> >>> -JB- >>> >>> >>>> The test tested the mode "difference", according to the Javadoc: >>>> If the counter difference mode is used, the value of the derived >>>> gauge is calculated as the difference between the observed counter >>>> values for two successive observations. >>>> >>>> The test set the first value and then waited 2 times of >>>> granularityperiod at line 171, hoped that the monitor would get the >>>> first observation during this waiting time, but the test could fail >>>> because granularityperiod * 2 was not enough and the test did the >>>> second >>>> set before the monitor did the first observation. >>>> >>>> It is easy to make the test timeout by commenting out the line 171. >>>> >>>> The proposed solution is to get informed when the monitor did >>>> observation on calling: >>>> StdObservedObject.getNbObjects(); >>>> >>>> Thanks, >>>> Shanliang >>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Dec 2 15:39:01 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 16:39:01 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DD929.2000401@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> Message-ID: <547DDD15.9000207@oracle.com> On 12/02/2014 04:22 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 12/02/2014 02:40 PM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>> Hi, >>>>> please review this test bug fix: >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>> >>>>> bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>> >>>> >>>> test/javax/management/monitor/CounterMonitorTest.java >>>> L61 - observedValue could be Integer >>> Could be, but not make difference, observedValue is only used with the >>> operation "==", like >>> while (value != observedValue) >> >> In that case having a correct type would make even more sense for the >> readability. > Agree in general:) but the variable "count" is declared as "Object" in > StdObservedObject, and "observedValue" is used to save observed "count" > value, so better to keep the same type for "more readability"? and avoid > a casting when setting "observedValue" Any reason 'count' is declared as Object? The value is effectively an integer value - only integer values are ever assigned to it. All the operations silently suppose this would be an integer and yet the type information is thrown away and the data is stored as Object. Feels very strange ... >> >>>> L225-238 - you could replace this block with the usage of Phaser (if >>>> you'd do that you could completely remove 'observedValue') >>> Not sure that it is a good idea to remove "observedValue" by using >>> Phaser, yes using Phaser can tell when the monitor does an observation, >>> but it is better to know which count value the monitor observed, in case >>> the thread was waked up accidentally. >> >> I don't think phaser can be confused by spurious wake-ups. >> >> If you want to keep the current way of synchronizing then you should >> make the 'count' variable volatile (L77) - it might be read and >> written to from different threads. > Phaser should not make a false wakeup, but use "observedValue" can make > sure that the observation happens on the right "count" value. > Yes "count" should be declared as "volatile". > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ Still using 'derivedGange' instead of 'derivedGauge' :( -JB- > > Thanks, > Shanliang > >> >> -JB- >> >>> >>> Thanks, >>> Shanliang >>>> >>>> -JB- >>>> >>>> >>>>> The test tested the mode "difference", according to the Javadoc: >>>>> If the counter difference mode is used, the value of the derived >>>>> gauge is calculated as the difference between the observed counter >>>>> values for two successive observations. >>>>> >>>>> The test set the first value and then waited 2 times of >>>>> granularityperiod at line 171, hoped that the monitor would get the >>>>> first observation during this waiting time, but the test could fail >>>>> because granularityperiod * 2 was not enough and the test did the >>>>> second >>>>> set before the monitor did the first observation. >>>>> >>>>> It is easy to make the test timeout by commenting out the line 171. >>>>> >>>>> The proposed solution is to get informed when the monitor did >>>>> observation on calling: >>>>> StdObservedObject.getNbObjects(); >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>>> >>>> >>> >> > From shanliang.jiang at oracle.com Tue Dec 2 16:22:52 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 02 Dec 2014 17:22:52 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DDD15.9000207@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> Message-ID: <547DE75C.6040303@oracle.com> Jaroslav Bachorik wrote: > On 12/02/2014 04:22 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 12/02/2014 02:40 PM, shanliang wrote: >>>> Jaroslav Bachorik wrote: >>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>> Hi, >>>>>> please review this test bug fix: >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>> >>>>> >>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>> L61 - observedValue could be Integer >>>> Could be, but not make difference, observedValue is only used with the >>>> operation "==", like >>>> while (value != observedValue) >>> >>> In that case having a correct type would make even more sense for the >>> readability. >> Agree in general:) but the variable "count" is declared as "Object" in >> StdObservedObject, and "observedValue" is used to save observed "count" >> value, so better to keep the same type for "more readability"? and avoid >> a casting when setting "observedValue" > > Any reason 'count' is declared as Object? The value is effectively an > integer value - only integer values are ever assigned to it. All the > operations silently suppose this would be an integer and yet the type > information is thrown away and the data is stored as Object. Feels > very strange ... I think a possible reason is that the CounterMonitor supports only Number type for comparing, and it accepts any type but detects whether the observed variable could be "matched" to Number, pass an Object type verifies this capability. > >>> >>>>> L225-238 - you could replace this block with the usage of Phaser (if >>>>> you'd do that you could completely remove 'observedValue') >>>> Not sure that it is a good idea to remove "observedValue" by using >>>> Phaser, yes using Phaser can tell when the monitor does an >>>> observation, >>>> but it is better to know which count value the monitor observed, in >>>> case >>>> the thread was waked up accidentally. >>> >>> I don't think phaser can be confused by spurious wake-ups. >>> >>> If you want to keep the current way of synchronizing then you should >>> make the 'count' variable volatile (L77) - it might be read and >>> written to from different threads. >> Phaser should not make a false wakeup, but use "observedValue" can make >> sure that the observation happens on the right "count" value. >> Yes "count" should be declared as "volatile". >> >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ > > Still using 'derivedGange' instead of 'derivedGauge' :( Oh I will change it before pushing, if no other modification. Thanks, Shanliang > > -JB- > >> >> Thanks, >> Shanliang >> >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Shanliang >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>> If the counter difference mode is used, the value of the >>>>>> derived >>>>>> gauge is calculated as the difference between the observed counter >>>>>> values for two successive observations. >>>>>> >>>>>> The test set the first value and then waited 2 times of >>>>>> granularityperiod at line 171, hoped that the monitor would get the >>>>>> first observation during this waiting time, but the test could fail >>>>>> because granularityperiod * 2 was not enough and the test did the >>>>>> second >>>>>> set before the monitor did the first observation. >>>>>> >>>>>> It is easy to make the test timeout by commenting out the line 171. >>>>>> >>>>>> The proposed solution is to get informed when the monitor did >>>>>> observation on calling: >>>>>> StdObservedObject.getNbObjects(); >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>>>> >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Dec 2 16:38:06 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 17:38:06 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DE75C.6040303@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> <547DE75C.6040303@oracle.com> Message-ID: <547DEAEE.9070607@oracle.com> On 12/02/2014 05:22 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 12/02/2014 04:22 PM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 12/02/2014 02:40 PM, shanliang wrote: >>>>> Jaroslav Bachorik wrote: >>>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>>> Hi, >>>>>>> please review this test bug fix: >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>>> >>>>>>> bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>>> >>>>>> >>>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>>> L61 - observedValue could be Integer >>>>> Could be, but not make difference, observedValue is only used with the >>>>> operation "==", like >>>>> while (value != observedValue) >>>> >>>> In that case having a correct type would make even more sense for the >>>> readability. >>> Agree in general:) but the variable "count" is declared as "Object" in >>> StdObservedObject, and "observedValue" is used to save observed "count" >>> value, so better to keep the same type for "more readability"? and avoid >>> a casting when setting "observedValue" >> >> Any reason 'count' is declared as Object? The value is effectively an >> integer value - only integer values are ever assigned to it. All the >> operations silently suppose this would be an integer and yet the type >> information is thrown away and the data is stored as Object. Feels >> very strange ... > I think a possible reason is that the CounterMonitor supports only > Number type for comparing, and it accepts any type but detects whether > the observed variable could be "matched" to Number, pass an Object type > verifies this capability. Hm, could you direct me to the code doing this? 'setAttribute' method seems to be inherited from 'Monitor' class and does not do any additional checks. Then 'Monitor.monitor()' uses 'getAttribute' (again, not overridden) to get back to the attribute :( Thanks, -JB- >> >>>> >>>>>> L225-238 - you could replace this block with the usage of Phaser (if >>>>>> you'd do that you could completely remove 'observedValue') >>>>> Not sure that it is a good idea to remove "observedValue" by using >>>>> Phaser, yes using Phaser can tell when the monitor does an >>>>> observation, >>>>> but it is better to know which count value the monitor observed, in >>>>> case >>>>> the thread was waked up accidentally. >>>> >>>> I don't think phaser can be confused by spurious wake-ups. >>>> >>>> If you want to keep the current way of synchronizing then you should >>>> make the 'count' variable volatile (L77) - it might be read and >>>> written to from different threads. >>> Phaser should not make a false wakeup, but use "observedValue" can make >>> sure that the observation happens on the right "count" value. >>> Yes "count" should be declared as "volatile". >>> >>> Here is the new version: >>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ >> >> Still using 'derivedGange' instead of 'derivedGauge' :( > Oh I will change it before pushing, if no other modification. > > Thanks, > Shanliang >> >> -JB- >> >>> >>> Thanks, >>> Shanliang >>> >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> Shanliang >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>>> If the counter difference mode is used, the value of the >>>>>>> derived >>>>>>> gauge is calculated as the difference between the observed counter >>>>>>> values for two successive observations. >>>>>>> >>>>>>> The test set the first value and then waited 2 times of >>>>>>> granularityperiod at line 171, hoped that the monitor would get the >>>>>>> first observation during this waiting time, but the test could fail >>>>>>> because granularityperiod * 2 was not enough and the test did the >>>>>>> second >>>>>>> set before the monitor did the first observation. >>>>>>> >>>>>>> It is easy to make the test timeout by commenting out the line 171. >>>>>>> >>>>>>> The proposed solution is to get informed when the monitor did >>>>>>> observation on calling: >>>>>>> StdObservedObject.getNbObjects(); >>>>>>> >>>>>>> Thanks, >>>>>>> Shanliang >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From shanliang.jiang at oracle.com Tue Dec 2 17:56:10 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 02 Dec 2014 18:56:10 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DEAEE.9070607@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> <547DE75C.6040303@oracle.com> <547DEAEE.9070607@oracle.com> Message-ID: <547DFD3A.400@oracle.com> Jaroslav Bachorik wrote: > On 12/02/2014 05:22 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 12/02/2014 04:22 PM, shanliang wrote: >>>> Jaroslav Bachorik wrote: >>>>> On 12/02/2014 02:40 PM, shanliang wrote: >>>>>> Jaroslav Bachorik wrote: >>>>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>>>> Hi, >>>>>>>> please review this test bug fix: >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>>>> >>>>>>>> bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>>>> >>>>>>> >>>>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>>>> L61 - observedValue could be Integer >>>>>> Could be, but not make difference, observedValue is only used >>>>>> with the >>>>>> operation "==", like >>>>>> while (value != observedValue) >>>>> >>>>> In that case having a correct type would make even more sense for the >>>>> readability. >>>> Agree in general:) but the variable "count" is declared as "Object" in >>>> StdObservedObject, and "observedValue" is used to save observed >>>> "count" >>>> value, so better to keep the same type for "more readability"? and >>>> avoid >>>> a casting when setting "observedValue" >>> >>> Any reason 'count' is declared as Object? The value is effectively an >>> integer value - only integer values are ever assigned to it. All the >>> operations silently suppose this would be an integer and yet the type >>> information is thrown away and the data is stored as Object. Feels >>> very strange ... >> I think a possible reason is that the CounterMonitor supports only >> Number type for comparing, and it accepts any type but detects whether >> the observed variable could be "matched" to Number, pass an Object type >> verifies this capability. > > Hm, could you direct me to the code doing this? 'setAttribute' method > seems to be inherited from 'Monitor' class and does not do any > additional checks. Then 'Monitor.monitor()' uses 'getAttribute' > (again, not overridden) to get back to the attribute :( ConterMonitor overrides Monitor.isComparableTypeValid(...) This method will be called by Monitor at the monitoring time and a Notification with the type "jmx.monitor.error.type" will be sent out if the observed attribute is not of type "Integer". Yes the monitor might have to do type check with the method: Monitor.setObservedAttribute("NbObjects"); but the Javadoc declares only: Throws: IllegalArgumentException - The specified attribute is null. maybe it is not sure that a monitor could do type check at setting time, for example if the MBeanInfo is null and getAttributeValue() returns null. Shanliang > > Thanks, > > -JB- > >>> >>>>> >>>>>>> L225-238 - you could replace this block with the usage of Phaser >>>>>>> (if >>>>>>> you'd do that you could completely remove 'observedValue') >>>>>> Not sure that it is a good idea to remove "observedValue" by using >>>>>> Phaser, yes using Phaser can tell when the monitor does an >>>>>> observation, >>>>>> but it is better to know which count value the monitor observed, in >>>>>> case >>>>>> the thread was waked up accidentally. >>>>> >>>>> I don't think phaser can be confused by spurious wake-ups. >>>>> >>>>> If you want to keep the current way of synchronizing then you should >>>>> make the 'count' variable volatile (L77) - it might be read and >>>>> written to from different threads. >>>> Phaser should not make a false wakeup, but use "observedValue" can >>>> make >>>> sure that the observation happens on the right "count" value. >>>> Yes "count" should be declared as "volatile". >>>> >>>> Here is the new version: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ >>> >>> Still using 'derivedGange' instead of 'derivedGauge' :( >> Oh I will change it before pushing, if no other modification. >> >> Thanks, >> Shanliang >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Shanliang >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>>>> If the counter difference mode is used, the value of the >>>>>>>> derived >>>>>>>> gauge is calculated as the difference between the observed counter >>>>>>>> values for two successive observations. >>>>>>>> >>>>>>>> The test set the first value and then waited 2 times of >>>>>>>> granularityperiod at line 171, hoped that the monitor would get >>>>>>>> the >>>>>>>> first observation during this waiting time, but the test could >>>>>>>> fail >>>>>>>> because granularityperiod * 2 was not enough and the test did the >>>>>>>> second >>>>>>>> set before the monitor did the first observation. >>>>>>>> >>>>>>>> It is easy to make the test timeout by commenting out the line >>>>>>>> 171. >>>>>>>> >>>>>>>> The proposed solution is to get informed when the monitor did >>>>>>>> observation on calling: >>>>>>>> StdObservedObject.getNbObjects(); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Dec 2 18:09:35 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 19:09:35 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547DFD3A.400@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> <547DE75C.6040303@oracle.com> <547DEAEE.9070607@oracle.com> <547DFD3A.400@oracle.com> Message-ID: <547E005F.8050003@oracle.com> On 12/02/2014 06:56 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 12/02/2014 05:22 PM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 12/02/2014 04:22 PM, shanliang wrote: >>>>> Jaroslav Bachorik wrote: >>>>>> On 12/02/2014 02:40 PM, shanliang wrote: >>>>>>> Jaroslav Bachorik wrote: >>>>>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>>>>> Hi, >>>>>>>>> please review this test bug fix: >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>>>>> >>>>>>>>> bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>>>>> >>>>>>>> >>>>>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>>>>> L61 - observedValue could be Integer >>>>>>> Could be, but not make difference, observedValue is only used >>>>>>> with the >>>>>>> operation "==", like >>>>>>> while (value != observedValue) >>>>>> >>>>>> In that case having a correct type would make even more sense for the >>>>>> readability. >>>>> Agree in general:) but the variable "count" is declared as "Object" in >>>>> StdObservedObject, and "observedValue" is used to save observed >>>>> "count" >>>>> value, so better to keep the same type for "more readability"? and >>>>> avoid >>>>> a casting when setting "observedValue" >>>> >>>> Any reason 'count' is declared as Object? The value is effectively an >>>> integer value - only integer values are ever assigned to it. All the >>>> operations silently suppose this would be an integer and yet the type >>>> information is thrown away and the data is stored as Object. Feels >>>> very strange ... >>> I think a possible reason is that the CounterMonitor supports only >>> Number type for comparing, and it accepts any type but detects whether >>> the observed variable could be "matched" to Number, pass an Object type >>> verifies this capability. >> >> Hm, could you direct me to the code doing this? 'setAttribute' method >> seems to be inherited from 'Monitor' class and does not do any >> additional checks. Then 'Monitor.monitor()' uses 'getAttribute' >> (again, not overridden) to get back to the attribute :( > ConterMonitor overrides Monitor.isComparableTypeValid(...) > > This method will be called by Monitor at the monitoring time and a > Notification with the type "jmx.monitor.error.type" will be sent out if > the observed attribute is not of type "Integer". > > Yes the monitor might have to do type check with the method: > Monitor.setObservedAttribute("NbObjects"); > > but the Javadoc declares only: > Throws: IllegalArgumentException - The specified attribute is null. > > maybe it is not sure that a monitor could do type check at setting time, > for example if the MBeanInfo is null and getAttributeValue() returns null. I still don't see how using Object instead of Integer type could check this functionality. But if you insist on keeping it this way I won't block fixing this failing test any further. Reviewed. -JB- > > Shanliang >> >> Thanks, >> >> -JB- >> >>>> >>>>>> >>>>>>>> L225-238 - you could replace this block with the usage of Phaser >>>>>>>> (if >>>>>>>> you'd do that you could completely remove 'observedValue') >>>>>>> Not sure that it is a good idea to remove "observedValue" by using >>>>>>> Phaser, yes using Phaser can tell when the monitor does an >>>>>>> observation, >>>>>>> but it is better to know which count value the monitor observed, in >>>>>>> case >>>>>>> the thread was waked up accidentally. >>>>>> >>>>>> I don't think phaser can be confused by spurious wake-ups. >>>>>> >>>>>> If you want to keep the current way of synchronizing then you should >>>>>> make the 'count' variable volatile (L77) - it might be read and >>>>>> written to from different threads. >>>>> Phaser should not make a false wakeup, but use "observedValue" can >>>>> make >>>>> sure that the observation happens on the right "count" value. >>>>> Yes "count" should be declared as "volatile". >>>>> >>>>> Here is the new version: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ >>>> >>>> Still using 'derivedGange' instead of 'derivedGauge' :( >>> Oh I will change it before pushing, if no other modification. >>> >>> Thanks, >>> Shanliang >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Shanliang >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>>>>> If the counter difference mode is used, the value of the >>>>>>>>> derived >>>>>>>>> gauge is calculated as the difference between the observed counter >>>>>>>>> values for two successive observations. >>>>>>>>> >>>>>>>>> The test set the first value and then waited 2 times of >>>>>>>>> granularityperiod at line 171, hoped that the monitor would get >>>>>>>>> the >>>>>>>>> first observation during this waiting time, but the test could >>>>>>>>> fail >>>>>>>>> because granularityperiod * 2 was not enough and the test did the >>>>>>>>> second >>>>>>>>> set before the monitor did the first observation. >>>>>>>>> >>>>>>>>> It is easy to make the test timeout by commenting out the line >>>>>>>>> 171. >>>>>>>>> >>>>>>>>> The proposed solution is to get informed when the monitor did >>>>>>>>> observation on calling: >>>>>>>>> StdObservedObject.getNbObjects(); >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From shanliang.jiang at oracle.com Tue Dec 2 18:17:38 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 02 Dec 2014 19:17:38 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547E005F.8050003@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> <547DE75C.6040303@oracle.com> <547DEAEE.9070607@oracle.com> <547DFD3A.400@oracle.com> <547E005F.8050003@oracle.com> Message-ID: <547E0242.4080807@oracle.com> Jaroslav Bachorik wrote: > On 12/02/2014 06:56 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 12/02/2014 05:22 PM, shanliang wrote: >>>> Jaroslav Bachorik wrote: >>>>> On 12/02/2014 04:22 PM, shanliang wrote: >>>>>> Jaroslav Bachorik wrote: >>>>>>> On 12/02/2014 02:40 PM, shanliang wrote: >>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>>>>>> Hi, >>>>>>>>>> please review this test bug fix: >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>>>>>> >>>>>>>>>> bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>>>>>> >>>>>>>>> >>>>>>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>>>>>> L61 - observedValue could be Integer >>>>>>>> Could be, but not make difference, observedValue is only used >>>>>>>> with the >>>>>>>> operation "==", like >>>>>>>> while (value != observedValue) >>>>>>> >>>>>>> In that case having a correct type would make even more sense >>>>>>> for the >>>>>>> readability. >>>>>> Agree in general:) but the variable "count" is declared as >>>>>> "Object" in >>>>>> StdObservedObject, and "observedValue" is used to save observed >>>>>> "count" >>>>>> value, so better to keep the same type for "more readability"? and >>>>>> avoid >>>>>> a casting when setting "observedValue" >>>>> >>>>> Any reason 'count' is declared as Object? The value is effectively an >>>>> integer value - only integer values are ever assigned to it. All the >>>>> operations silently suppose this would be an integer and yet the type >>>>> information is thrown away and the data is stored as Object. Feels >>>>> very strange ... >>>> I think a possible reason is that the CounterMonitor supports only >>>> Number type for comparing, and it accepts any type but detects whether >>>> the observed variable could be "matched" to Number, pass an Object >>>> type >>>> verifies this capability. >>> >>> Hm, could you direct me to the code doing this? 'setAttribute' method >>> seems to be inherited from 'Monitor' class and does not do any >>> additional checks. Then 'Monitor.monitor()' uses 'getAttribute' >>> (again, not overridden) to get back to the attribute :( >> ConterMonitor overrides Monitor.isComparableTypeValid(...) >> >> This method will be called by Monitor at the monitoring time and a >> Notification with the type "jmx.monitor.error.type" will be sent out if >> the observed attribute is not of type "Integer". >> >> Yes the monitor might have to do type check with the method: >> Monitor.setObservedAttribute("NbObjects"); >> >> but the Javadoc declares only: >> Throws: IllegalArgumentException - The specified attribute is null. >> >> maybe it is not sure that a monitor could do type check at setting time, >> for example if the MBeanInfo is null and getAttributeValue() returns >> null. > > I still don't see how using Object instead of Integer type could check > this functionality. But if you insist on keeping it this way I won't > block fixing this failing test any further. Reviewed. You can simply pass an Object instead of an Integer to NbObjects, and see what happen. The monitor does type check only at monitoring time. Thanks for review. Shanliang > > -JB- > >> >> Shanliang >>> >>> Thanks, >>> >>> -JB- >>> >>>>> >>>>>>> >>>>>>>>> L225-238 - you could replace this block with the usage of Phaser >>>>>>>>> (if >>>>>>>>> you'd do that you could completely remove 'observedValue') >>>>>>>> Not sure that it is a good idea to remove "observedValue" by using >>>>>>>> Phaser, yes using Phaser can tell when the monitor does an >>>>>>>> observation, >>>>>>>> but it is better to know which count value the monitor >>>>>>>> observed, in >>>>>>>> case >>>>>>>> the thread was waked up accidentally. >>>>>>> >>>>>>> I don't think phaser can be confused by spurious wake-ups. >>>>>>> >>>>>>> If you want to keep the current way of synchronizing then you >>>>>>> should >>>>>>> make the 'count' variable volatile (L77) - it might be read and >>>>>>> written to from different threads. >>>>>> Phaser should not make a false wakeup, but use "observedValue" can >>>>>> make >>>>>> sure that the observation happens on the right "count" value. >>>>>> Yes "count" should be declared as "volatile". >>>>>> >>>>>> Here is the new version: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ >>>>> >>>>> Still using 'derivedGange' instead of 'derivedGauge' :( >>>> Oh I will change it before pushing, if no other modification. >>>> >>>> Thanks, >>>> Shanliang >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>>>>>> If the counter difference mode is used, the value of the >>>>>>>>>> derived >>>>>>>>>> gauge is calculated as the difference between the observed >>>>>>>>>> counter >>>>>>>>>> values for two successive observations. >>>>>>>>>> >>>>>>>>>> The test set the first value and then waited 2 times of >>>>>>>>>> granularityperiod at line 171, hoped that the monitor would get >>>>>>>>>> the >>>>>>>>>> first observation during this waiting time, but the test could >>>>>>>>>> fail >>>>>>>>>> because granularityperiod * 2 was not enough and the test did >>>>>>>>>> the >>>>>>>>>> second >>>>>>>>>> set before the monitor did the first observation. >>>>>>>>>> >>>>>>>>>> It is easy to make the test timeout by commenting out the line >>>>>>>>>> 171. >>>>>>>>>> >>>>>>>>>> The proposed solution is to get informed when the monitor did >>>>>>>>>> observation on calling: >>>>>>>>>> StdObservedObject.getNbObjects(); >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Dec 2 18:47:16 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 19:47:16 +0100 Subject: jmx-dev Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547E0242.4080807@oracle.com> References: <547C7218.2040001@oracle.com> <547C7FDE.5020808@oracle.com> <547DC14D.1070308@oracle.com> <547DD364.7080100@oracle.com> <547DD929.2000401@oracle.com> <547DDD15.9000207@oracle.com> <547DE75C.6040303@oracle.com> <547DEAEE.9070607@oracle.com> <547DFD3A.400@oracle.com> <547E005F.8050003@oracle.com> <547E0242.4080807@oracle.com> Message-ID: <547E0934.7050107@oracle.com> On 12/02/2014 07:17 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 12/02/2014 06:56 PM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 12/02/2014 05:22 PM, shanliang wrote: >>>>> Jaroslav Bachorik wrote: >>>>>> On 12/02/2014 04:22 PM, shanliang wrote: >>>>>>> Jaroslav Bachorik wrote: >>>>>>>> On 12/02/2014 02:40 PM, shanliang wrote: >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>> On 12/01/2014 02:50 PM, shanliang wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> please review this test bug fix: >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ >>>>>>>>>>> >>>>>>>>>>> bug: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065764 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/javax/management/monitor/CounterMonitorTest.java >>>>>>>>>> L61 - observedValue could be Integer >>>>>>>>> Could be, but not make difference, observedValue is only used >>>>>>>>> with the >>>>>>>>> operation "==", like >>>>>>>>> while (value != observedValue) >>>>>>>> >>>>>>>> In that case having a correct type would make even more sense >>>>>>>> for the >>>>>>>> readability. >>>>>>> Agree in general:) but the variable "count" is declared as >>>>>>> "Object" in >>>>>>> StdObservedObject, and "observedValue" is used to save observed >>>>>>> "count" >>>>>>> value, so better to keep the same type for "more readability"? and >>>>>>> avoid >>>>>>> a casting when setting "observedValue" >>>>>> >>>>>> Any reason 'count' is declared as Object? The value is effectively an >>>>>> integer value - only integer values are ever assigned to it. All the >>>>>> operations silently suppose this would be an integer and yet the type >>>>>> information is thrown away and the data is stored as Object. Feels >>>>>> very strange ... >>>>> I think a possible reason is that the CounterMonitor supports only >>>>> Number type for comparing, and it accepts any type but detects whether >>>>> the observed variable could be "matched" to Number, pass an Object >>>>> type >>>>> verifies this capability. >>>> >>>> Hm, could you direct me to the code doing this? 'setAttribute' method >>>> seems to be inherited from 'Monitor' class and does not do any >>>> additional checks. Then 'Monitor.monitor()' uses 'getAttribute' >>>> (again, not overridden) to get back to the attribute :( >>> ConterMonitor overrides Monitor.isComparableTypeValid(...) >>> >>> This method will be called by Monitor at the monitoring time and a >>> Notification with the type "jmx.monitor.error.type" will be sent out if >>> the observed attribute is not of type "Integer". >>> >>> Yes the monitor might have to do type check with the method: >>> Monitor.setObservedAttribute("NbObjects"); >>> >>> but the Javadoc declares only: >>> Throws: IllegalArgumentException - The specified attribute is null. >>> >>> maybe it is not sure that a monitor could do type check at setting time, >>> for example if the MBeanInfo is null and getAttributeValue() returns >>> null. >> >> I still don't see how using Object instead of Integer type could check >> this functionality. But if you insist on keeping it this way I won't >> block fixing this failing test any further. Reviewed. > You can simply pass an Object instead of an Integer to NbObjects, and > see what happen. The monitor does type check only at monitoring time. You can but you are passing Integer instance which are just dressed as Objects anyway :) -JB- > > Thanks for review. > Shanliang >> >> -JB- >> >>> >>> Shanliang >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>>>> >>>>>>>> >>>>>>>>>> L225-238 - you could replace this block with the usage of Phaser >>>>>>>>>> (if >>>>>>>>>> you'd do that you could completely remove 'observedValue') >>>>>>>>> Not sure that it is a good idea to remove "observedValue" by using >>>>>>>>> Phaser, yes using Phaser can tell when the monitor does an >>>>>>>>> observation, >>>>>>>>> but it is better to know which count value the monitor >>>>>>>>> observed, in >>>>>>>>> case >>>>>>>>> the thread was waked up accidentally. >>>>>>>> >>>>>>>> I don't think phaser can be confused by spurious wake-ups. >>>>>>>> >>>>>>>> If you want to keep the current way of synchronizing then you >>>>>>>> should >>>>>>>> make the 'count' variable volatile (L77) - it might be read and >>>>>>>> written to from different threads. >>>>>>> Phaser should not make a false wakeup, but use "observedValue" can >>>>>>> make >>>>>>> sure that the observation happens on the right "count" value. >>>>>>> Yes "count" should be declared as "volatile". >>>>>>> >>>>>>> Here is the new version: >>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065764/01/ >>>>>> >>>>>> Still using 'derivedGange' instead of 'derivedGauge' :( >>>>> Oh I will change it before pushing, if no other modification. >>>>> >>>>> Thanks, >>>>> Shanliang >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Shanliang >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The test tested the mode "difference", according to the Javadoc: >>>>>>>>>>> If the counter difference mode is used, the value of the >>>>>>>>>>> derived >>>>>>>>>>> gauge is calculated as the difference between the observed >>>>>>>>>>> counter >>>>>>>>>>> values for two successive observations. >>>>>>>>>>> >>>>>>>>>>> The test set the first value and then waited 2 times of >>>>>>>>>>> granularityperiod at line 171, hoped that the monitor would get >>>>>>>>>>> the >>>>>>>>>>> first observation during this waiting time, but the test could >>>>>>>>>>> fail >>>>>>>>>>> because granularityperiod * 2 was not enough and the test did >>>>>>>>>>> the >>>>>>>>>>> second >>>>>>>>>>> set before the monitor did the first observation. >>>>>>>>>>> >>>>>>>>>>> It is easy to make the test timeout by commenting out the line >>>>>>>>>>> 171. >>>>>>>>>>> >>>>>>>>>>> The proposed solution is to get informed when the monitor did >>>>>>>>>>> observation on calling: >>>>>>>>>>> StdObservedObject.getNbObjects(); >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Mon Dec 8 08:36:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 08:36:52 +0000 Subject: jmx-dev JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module In-Reply-To: <54854D86.5040501@oracle.com> References: <54854D86.5040501@oracle.com> Message-ID: <54856324.8030504@oracle.com> I assume you meant to cc jmx-dev for this one. In any case it looks okay to me. -Alan On 08/12/2014 07:04, joe darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8066634: Suppress deprecation warnings in java.management module > > Thanks, > > -Joe > > diff -r 913808eaf19a > src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > --- > a/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Mon Nov 10 08:43:27 2014 -0800 > +++ > b/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Sun Dec 07 23:02:51 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1707,16 +1707,19 @@ > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(ObjectName name, byte[] > data) throws InstanceNotFoundException, > OperationsException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, byte[] > data) throws OperationsException, > ReflectionException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, ObjectName > loaderName, > byte[] data) throws InstanceNotFoundException, > OperationsException, > ReflectionException { > From shanliang.jiang at oracle.com Fri Dec 12 07:33:49 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 08:33:49 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value Message-ID: <548A9A5D.6020000@oracle.com> Hi, It is a test bug, it is not correct: while(!wb.done || timeToWait > 0) { it should be: while(!wb.done && timeToWait > 0) { || should be changed to && Another issue is that the waiting time could be not enough (final long timeout = 2000). The fix is to remove the waiting time specified in the test, the timeout of test harness will be used as the max waiting time. bug: https://bugs.openjdk.java.net/browse/JDK-8067241 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ thanks, Shanliang From daniel.fuchs at oracle.com Fri Dec 12 08:34:23 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 09:34:23 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548A9A5D.6020000@oracle.com> References: <548A9A5D.6020000@oracle.com> Message-ID: <548AA88F.3050401@oracle.com> Hi Shanliang, These two statements are no longer needed and should be removed - as they are misleading: 64 if (!bb.gotLock) { 65 throw new RuntimeException("Failed to get lock, impossible!"); 66 } 81 if (!wb.done) { 82 throw new RuntimeException("It is blocked!"); 83 } which makes me wonder whether your changes are deeper than intended. Now the test will either succeed, or fail in jtreg timeout. The condition "It is blocked!" can no longer be detected by the test. Is that your intention? If that's your intention - I guess it is OK - but maybe it would deserve a comment in the @summary of the test. Something like 'This bug attempts to reproduce a deadlock situation and will block forever if the deadlock is present.' best regards, -- daniel On 12/12/14 8:33 AM, shanliang wrote: > Hi, > > It is a test bug, it is not correct: > while(!wb.done || timeToWait > 0) { > > it should be: > while(!wb.done && timeToWait > 0) { > > || should be changed to && > > Another issue is that the waiting time could be not enough (final long > timeout = 2000). > > The fix is to remove the waiting time specified in the test, the > timeout of test harness will be used as the max waiting time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067241 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ > > thanks, > Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Fri Dec 12 08:56:35 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 09:56:35 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AA88F.3050401@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> Message-ID: <548AADC3.30301@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > These two statements are no longer needed and should be removed - as they > are misleading: > > 64 if (!bb.gotLock) { > 65 throw new RuntimeException("Failed to get lock, impossible!"); > 66 } > > > 81 if (!wb.done) { > 82 throw new RuntimeException("It is blocked!"); > 83 } > Yes, can be removed. > > > which makes me wonder whether your changes are deeper than intended. > Now the test will either succeed, or fail in jtreg timeout. The condition > "It is blocked!" > can no longer be detected by the test. Is that your intention? If that's > your intention - I guess it is OK - but maybe it would deserve a comment > in the @summary of the test. Something like 'This bug attempts to > reproduce > a deadlock situation and will block forever if the deadlock is present.' Updated. Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ Thanks, Shanliang > > best regards, > > -- daniel > > On 12/12/14 8:33 AM, shanliang wrote: >> Hi, >> >> It is a test bug, it is not correct: >> while(!wb.done || timeToWait > 0) { >> >> it should be: >> while(!wb.done && timeToWait > 0) { >> >> || should be changed to && >> >> Another issue is that the waiting time could be not enough (final >> long timeout = 2000). >> >> The fix is to remove the waiting time specified in the test, the >> timeout of test harness will be used as the max waiting time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >> >> thanks, >> Shanliang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Dec 12 09:11:31 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Dec 2014 01:11:31 -0800 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548A9A5D.6020000@oracle.com> References: <548A9A5D.6020000@oracle.com> Message-ID: <548AB143.8070808@oracle.com> Hi Shanliang, The fix is good. Just a side note... I do not see why the line 98 is needed as no other thread is going to sync on the DeadlockTest object (that is o) that is passed to the BadBoy constructor: 98 synchronized(o) { Thanks, Serguei On 12/11/14 11:33 PM, shanliang wrote: > Hi, > > It is a test bug, it is not correct: > while(!wb.done || timeToWait > 0) { > > it should be: > while(!wb.done && timeToWait > 0) { > > || should be changed to && > > Another issue is that the waiting time could be not enough (final long > timeout = 2000). > > The fix is to remove the waiting time specified in the test, the > timeout of test harness will be used as the max waiting time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067241 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ > > thanks, > Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Dec 12 10:15:11 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 11:15:11 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AB143.8070808@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AB143.8070808@oracle.com> Message-ID: <548AC02F.7000307@oracle.com> On 12/12/14 10:11, serguei.spitsyn at oracle.com wrote: > Hi Shanliang, > > The fix is good. > > Just a side note... > I do not see why the line 98 is needed as no other thread is going to sync > on the DeadlockTest object (that is o) that is passed to the BadBoy > constructor: > > 98 synchronized(o) { Hi Sergey, I believe this is the purpose of the test. See https://bugs.openjdk.java.net/browse/JDK-6331746 best regards, -- daniel > > > Thanks, > Serguei > > > On 12/11/14 11:33 PM, shanliang wrote: >> Hi, >> >> It is a test bug, it is not correct: >> while(!wb.done || timeToWait > 0) { >> >> it should be: >> while(!wb.done && timeToWait > 0) { >> >> || should be changed to && >> >> Another issue is that the waiting time could be not enough (final long >> timeout = 2000). >> >> The fix is to remove the waiting time specified in the test, the >> timeout of test harness will be used as the max waiting time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >> >> thanks, >> Shanliang > From serguei.spitsyn at oracle.com Fri Dec 12 10:30:26 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Dec 2014 02:30:26 -0800 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AC02F.7000307@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AB143.8070808@oracle.com> <548AC02F.7000307@oracle.com> Message-ID: <548AC3C2.5000902@oracle.com> Thank you, Daniel! It is clear now. Thanks, Serguei On 12/12/14 2:15 AM, Daniel Fuchs wrote: > On 12/12/14 10:11, serguei.spitsyn at oracle.com wrote: >> Hi Shanliang, >> >> The fix is good. >> >> Just a side note... >> I do not see why the line 98 is needed as no other thread is going to >> sync >> on the DeadlockTest object (that is o) that is passed to the BadBoy >> constructor: >> >> 98 synchronized(o) { > > Hi Sergey, > > I believe this is the purpose of the test. > See https://bugs.openjdk.java.net/browse/JDK-6331746 > > best regards, > > -- daniel > >> >> >> Thanks, >> Serguei >> >> >> On 12/11/14 11:33 PM, shanliang wrote: >>> Hi, >>> >>> It is a test bug, it is not correct: >>> while(!wb.done || timeToWait > 0) { >>> >>> it should be: >>> while(!wb.done && timeToWait > 0) { >>> >>> || should be changed to && >>> >>> Another issue is that the waiting time could be not enough (final long >>> timeout = 2000). >>> >>> The fix is to remove the waiting time specified in the test, the >>> timeout of test harness will be used as the max waiting time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >>> >>> thanks, >>> Shanliang >> > From shanliang.jiang at oracle.com Fri Dec 12 12:44:10 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 13:44:10 +0100 Subject: jmx-dev RFR: 8066952 [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs Message-ID: <548AE31A.8050109@oracle.com> Hi, As Daniel said: "I think that what happens here is that the StdObservedObject.getNbObjects() getter unblocks the main thread before returning the value to the monitor. This makes it possible to have a race condition where the next setNbObjects called by the main thread can then occur before the result of StdObservedObject.getNbObjects() is taken into account - and even before the StdObservedObject.getNbObjects() actually returns. So StdObservedObject.getNbObjects() may return a value different than the one which was observed. In our case, it would return 3 (the newer value) instead of 0 (the value that was observed). " The suggested fix is to return "observedValue" instead of "count", in this way we check also that the monitor never starts next observation before the current one finishes. bug: https://bugs.openjdk.java.net/browse/JDK-8066952 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8066952/00/ Thanks, Shanliang From daniel.fuchs at oracle.com Fri Dec 12 13:05:32 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 14:05:32 +0100 Subject: jmx-dev RFR: 8066952 [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <548AE31A.8050109@oracle.com> References: <548AE31A.8050109@oracle.com> Message-ID: <548AE81C.5040405@oracle.com> On 12/12/14 13:44, shanliang wrote: > Hi, > > As Daniel said: "I think that what happens here is that the > StdObservedObject.getNbObjects() getter unblocks the main thread before > returning the value to the monitor. This makes it possible to have a > race condition where the next setNbObjects called by the main thread can > then occur before the result of StdObservedObject.getNbObjects() is > taken into account - and even before the > StdObservedObject.getNbObjects() actually returns. So > StdObservedObject.getNbObjects() may return a value different than the > one which was observed. In our case, it would return 3 (the newer value) > instead of 0 (the value that was observed). " > > The suggested fix is to return "observedValue" instead of "count", in > this way we check also that the monitor never starts next observation > before the current one finishes. Looks good Shanliang! -- daniel > > bug: https://bugs.openjdk.java.net/browse/JDK-8066952 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8066952/00/ > > Thanks, > Shanliang From jaroslav.bachorik at oracle.com Fri Dec 12 14:05:29 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 12 Dec 2014 15:05:29 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AADC3.30301@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> <548AADC3.30301@oracle.com> Message-ID: <548AF629.7040700@oracle.com> Hi, On 12/12/2014 09:56 AM, shanliang wrote: > Daniel Fuchs wrote: >> Hi Shanliang, >> >> These two statements are no longer needed and should be removed - as they >> are misleading: >> >> 64 if (!bb.gotLock) { >> 65 throw new RuntimeException("Failed to get lock, impossible!"); >> 66 } >> >> >> 81 if (!wb.done) { >> 82 throw new RuntimeException("It is blocked!"); >> 83 } >> > Yes, can be removed. >> >> >> which makes me wonder whether your changes are deeper than intended. >> Now the test will either succeed, or fail in jtreg timeout. The condition >> "It is blocked!" >> can no longer be detected by the test. Is that your intention? If that's >> your intention - I guess it is OK - but maybe it would deserve a comment >> in the @summary of the test. Something like 'This bug attempts to >> reproduce >> a deadlock situation and will block forever if the deadlock is present.' > Updated. > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ I know that I'm starting to repeat myself but couldn't you replace L58-61 and L91-95 with a simple Phaser? Like ``` L58-61: Phaser p = new Phaser(2); p.arriveAndAwaitAdvance() Then pass the Phaser instance to BadBoy and L91-95: p.arriveAndAwaitAdvance(); ``` This way the main thread is blocked till the BadBoy thread has acquired the BadBoy's lock and the code is more concise. -JB- > > Thanks, > Shanliang > >> >> best regards, >> >> -- daniel >> >> On 12/12/14 8:33 AM, shanliang wrote: >>> Hi, >>> >>> It is a test bug, it is not correct: >>> while(!wb.done || timeToWait > 0) { >>> >>> it should be: >>> while(!wb.done && timeToWait > 0) { >>> >>> || should be changed to && >>> >>> Another issue is that the waiting time could be not enough (final >>> long timeout = 2000). >>> >>> The fix is to remove the waiting time specified in the test, the >>> timeout of test harness will be used as the max waiting time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >>> >>> thanks, >>> Shanliang >> > From daniel.fuchs at oracle.com Mon Dec 15 17:38:39 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Dec 2014 18:38:39 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AADC3.30301@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> <548AADC3.30301@oracle.com> Message-ID: <548F1C9F.2090000@oracle.com> On 12/12/14 09:56, shanliang wrote: > Updated. > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ > > Thanks, > Shanliang Hi Shanliang, Your changes looks good to me. WRT using a Phaser, it would require a careful analysis to assert that modifying the locking strategy - especially things like 90 synchronized(o) { 91 synchronized(this) { 92 gotLock = true; 93 94 this.notify(); 95 } still preserve the nature of the test. I wonder if it's worth the trouble. best regards, -- daniel From shanliang.jiang at oracle.com Mon Dec 15 18:14:55 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 15 Dec 2014 19:14:55 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AF629.7040700@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> <548AADC3.30301@oracle.com> <548AF629.7040700@oracle.com> Message-ID: <548F251F.3070903@oracle.com> Jaroslav Bachorik wrote: > Hi, > > On 12/12/2014 09:56 AM, shanliang wrote: >> Daniel Fuchs wrote: >>> Hi Shanliang, >>> >>> These two statements are no longer needed and should be removed - as >>> they >>> are misleading: >>> >>> 64 if (!bb.gotLock) { >>> 65 throw new RuntimeException("Failed to get lock, >>> impossible!"); >>> 66 } >>> >>> >>> 81 if (!wb.done) { >>> 82 throw new RuntimeException("It is blocked!"); >>> 83 } >>> >> Yes, can be removed. >>> >>> >>> which makes me wonder whether your changes are deeper than intended. >>> Now the test will either succeed, or fail in jtreg timeout. The >>> condition >>> "It is blocked!" >>> can no longer be detected by the test. Is that your intention? If >>> that's >>> your intention - I guess it is OK - but maybe it would deserve a >>> comment >>> in the @summary of the test. Something like 'This bug attempts to >>> reproduce >>> a deadlock situation and will block forever if the deadlock is >>> present.' >> Updated. >> >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ > > I know that I'm starting to repeat myself but couldn't you replace > L58-61 and L91-95 with a simple Phaser? > > Like > ``` > > L58-61: Phaser p = new Phaser(2); p.arriveAndAwaitAdvance() > > Then pass the Phaser instance to BadBoy and > > L91-95: p.arriveAndAwaitAdvance(); > ``` > > This way the main thread is blocked till the BadBoy thread has > acquired the BadBoy's lock and the code is more concise. I agree Daniel's comment that we may need more investigation for using Phaser, Phaser might be a good solution but the current synchronization solution should work too and I have ran the test on jprt. So let's keep the current solution and investivating on Phaser if the test fails again. Shanliang > > -JB- > > >> >> Thanks, >> Shanliang >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 12/12/14 8:33 AM, shanliang wrote: >>>> Hi, >>>> >>>> It is a test bug, it is not correct: >>>> while(!wb.done || timeToWait > 0) { >>>> >>>> it should be: >>>> while(!wb.done && timeToWait > 0) { >>>> >>>> || should be changed to && >>>> >>>> Another issue is that the waiting time could be not enough (final >>>> long timeout = 2000). >>>> >>>> The fix is to remove the waiting time specified in the test, the >>>> timeout of test harness will be used as the max waiting time. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >>>> >>>> thanks, >>>> Shanliang >>> >> >