On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> 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. > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > Show log output @kevinjwalls is this going to be impacted by: https://github.com/openjdk/jdk/pull/8831 ? ------------- PR: https://git.openjdk.org/jdk/pull/9309
