Test has been problemlisted for a long time due to intermittent failures. This is a difficult test as it tries to monitor usage thresholds on Memory Pools which are outside its control. Not just Java heap pools, where the allocation it makes may or may not affect a particuclar pool, but non-heap pools such as CodeHeap and Metadata, where other activity in the VM can affect their usage and surprise the test.
The test iterates JMX memory pools where thresholds are supported, sets a threshold one byte higher than current usage, and makes an allocation. This only makes sense on Java heap pools. It is tempting to skip non-heap pools, but this test can still give a sanity test about threshold behaviour. That is actually its main purpose, as the allocation is unlikely to affect the pool being tested. With the changes here, I'm seeing the test and all its variations pass reliably, i.e. 50 iterations in each tested platform. Skip testing a non-heap memory pool, e.g. CodeHeap, if it is hitting the threshold while we test, because that means it is changing outside our control. Also re-test isExceeded on failure, as fetching the usage and isExceeded is a race. Logging of more pool stats to better understand failures. ------------- Commit messages: - 8198668: MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java still failing Changes: https://git.openjdk.org/jdk/pull/9309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8198668 Stats: 70 lines in 2 files changed: 32 ins; 10 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9309.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9309/head:pull/9309 PR: https://git.openjdk.org/jdk/pull/9309
