Hi,
Please review modified webrev incorporating Staffan's comments.
http://cr.openjdk.java.net/~hb/8151345/webrev.01/
Thanks
Harsha
On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote:
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
