RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]

[Kevin Walls]

On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon <dnsimon at 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