On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsi...@openjdk.org> wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can >> transiently fail when run with `-Xcomp`. This happens when the compilation >> of methods on the worker threads interleaves with the 2 calls on the main >> thread to `mbean.getThreadCpuTime` to get the CPU time for all worker >> threads. >> >> The way the test is currently written, the worker threads are all usually >> waiting on a shared monitor when the 2 timings are taken. That is, in a >> successful run, the delta between the timings is always 0. When `-Xcomp` >> compilations kick in at the "wrong" time or take sufficiently long, the >> expected delta of 100 nanoseconds is easily exceeded. >> >> It does not make sense to run a timing test with such a small expected delta >> with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. > > Doug Simon has updated the pull request incrementally with one additional > commit since the last revision: > > fix date in header Yes, if you're idle, you should not have used any cpu time, that's what I think it's testing, and the 100 ms slack (DELTA) to account for slack in the accounting. If compilation makes a thread state Thread.State.WAITING then it would fool the check in waitUntilThreadBlocked(). Next time it causes trouble that check could be revisited... 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923615761
