Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon 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
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
On Fri, 2 Feb 2024 10:48:26 GMT, Kevin Walls wrote: > Or maybe they are not done the initial -Xcomp compile and > waitUntilThreadBlocked() is mistakenly thinking they are now idle... Yes, I believe this is the case. It's not really clear to me what the test is testing. As far as I can see, if the 2 timings are meant to be taken when the worker threads are idle, I would have thought the expected delta should be 0. - PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923578655
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon 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
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon 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 Thanks for the reviews. - PR Comment: https://git.openjdk.org/jdk/pull/17675#issuecomment-1923543404
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon 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 Looks good. Thank you for fixing! - Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858895296
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
> 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 - Changes: - all: https://git.openjdk.org/jdk/pull/17675/files - new: https://git.openjdk.org/jdk/pull/17675/files/4ff2f7cd..a3bc2653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range
On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon 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. Excluding Xcomp mode seems the most practical/expedient solution. Please update the 2023 copyright year to 2024. Thanks. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858173944
RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range
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. - Commit messages: - disable ThreadCpuTimeArray with xcomp Changes: https://git.openjdk.org/jdk/pull/17675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17675&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325137 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675
