On Wed, 30 Apr 2025 17:44:09 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> This is hard to reproduce, and at first I'd only seen -1 returned on the >> first calls to mbean.getProcessCpuLoad(). >> But eventually I observed a -1 at any time, including in middle of the >> iterations, or on the last iteration which makes the current test fail. >> >> Should fail on Windows only if we only ever see -1 returned from >> getProcessCpuLoad(). >> Remove the "exclusiveAccess.dirs=." (JDK-8353231 adding >> "exclusiveAccess.dirs=." did not fix this.) > > test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line > 60: > >> 58: // A good reading: forget any previous -1. >> 59: ex = null; >> 60: good++; > > The `ex = null` is a little misleading because actually it's irrelevant. An > error on the next iteration will set it again, but it will be ignored because > `good != 0`. Yes, as long as there is a good value captured, Windows should pass. We could get into how many good values we should see, I might suggest 6 out of 10? But that seems like a guessing game. The breakage in this feature before meant it could never return a good value, that's what we need to guard against. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24961#discussion_r2069241694
