If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use
assertEQorGTE() and you won’t have to change CodeCacheUtils.java. Or am I
missing something?
> On 12 aug. 2016, at 17:26, Harsha Wardhana B
> wrote:
>
> Hi,
>
> Please review modified webrev incorporating Staffan'
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 pro
Hi,
Could you, please, review the following test-only change (adding a new test):
CR: https://bugs.openjdk.java.net/browse/JDK-8148103
Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/
The new test verifies the new JDWP commands: AllModules, Module, Name,
ClassLoader, CanRead.
It does s
David,
Updated webrev is:
http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/
Windows is absolutely different story that requires significant efforts
to reproduce error conditions and test changes. Also it has nothing to
do with ARMv7.
So I would prefer to address windows issues separ
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 met
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 i
