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 It doesn't seem that critical to test this with -Xcomp But just checking: the threads are meant to be waiting, after we call waitUntilThreadBlocked(), so do they wake up and do some deopt or compilation work for some reason? Or maybe they are not done the initial -Xcomp compile and waitUntilThreadBlocked() is mistakenly thinking they are now idle... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923550642
