RFR: 8303136: MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded005 failed with "isCollectionUsageThresholdExceeded() returned true, while threshold = 1 and used = 0"
Kevin Walls
kevinw at openjdk.org
Thu Mar 2 21:43:17 UTC 2023
On Thu, 2 Mar 2023 18:00:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Test update for an occasional failure, which does not reproduce.
>>
>> The test failure in JDK-8303136 is at line 141 in the updated file here. It's the failure where isExceeded is true, but our sampled "used" value is not above the threshold. But while the comment says it's refreshing values, it does not not refresh "used", so there could have been gc/promotion activity which hits the threshold outside of the test's control. Refreshing "used" is the addition here.
>>
>> Separately, the code at line 123 in the new file also claims to refresh the values, but it only refreshes the threshold, which we aren't changing. Not making it refresh "used" at that point looks correct, so remove the "if (used >= threshold)" as we have already checked that at line 116.
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded001.java line 126:
>
>> 124: threshold = monitor.getCollectionThreshold(pool);
>> 125: usage = monitor.getCollectionUsage(pool);
>> 126: if (used >= threshold) {
>
> Although `used` is not updated, `threshold` is. Couldn't removing this extra check result in new failures?
I think that's OK. We set the threshold earlier in the test, to the value of used+1, we don't need to read threshold back again. I see in testing that it reads back the value that it set, as it should, this value isn't changed again.
(The test's monitor.setCollectionThreshold method (MemoryMonitor.java) for setting this ends up calling into MemoryPoolImpl.java)
The testing at lines 116 - 121 is checking if we have crossed the threshold, and if so then isExceeded really should be true. It's surviving testing so far!
-------------
PR: https://git.openjdk.org/jdk/pull/12823
More information about the serviceability-dev
mailing list