Harsha, Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important.
Thanks, /Staffan > On 12 aug. 2016, at 10:07, Harsha Wardhana B <harsha.wardhan...@oracle.com> > wrote: > > Hello, > > I forgot to put-in the fix details. > > The test was failing because of a race condition caused by the order in which > MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It > is possible that intermediate allocations can happen which can lead to > getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct > order would be to capture getUsage and then capture getPeakUsage in order to > account for intermediate allocations. > > Thanks > > Harsha > > > On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >> Hello, >> >> Could one of you please review the below fix? >> >> Thanks >> Harsha >> >> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>> Please use following alias for compiler tests (hotspot/test/compiler): >>> >>> hotspot-compiler-...@openjdk.java.net >>> >>> Leonid >>> >>> >>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>> Gentle Reminder !! >>>> >>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review the below simple test fix for the issue, >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>> >>>>> with webrev located at, >>>>> >>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>> >>> >> >
