On Mon, 8 Jul 2024 18:13:33 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> There are two similarly names tests. >> Recently: >> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed >> with CPU time out of expected range >> ...made a simple change to try and avoid noisy test failures. The same fix >> should be applied here to ThreadCpuTime.java. >> >> Also removing an old comment about a Solaris issue. > > test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239: > >> 237: " > ThreadUserTime = " + utime2); >> 238: } >> 239: */ > > Shouldn't this be uncommented and this bit of testing restored? It seems the > only reason it was commented out is because of Solaris, which we don't need > to worry about anymore. Probably best to leave this to a separate PR if you > are going to restore it. Would have been happy to test it and bring it back, have looked into it more: back in jdk5u we have the same commented out code, we have never run this in general testing. I think it's redundant, the two calls are equivalent. long utime1 = mbean.getCurrentThreadUserTime(); "This is a convenient method for local management use and is equivalent to calling: getThreadUserTime(Thread.currentThread().getId());" ..which is the other time we would be comparing it with: long utime2 = mbean.getThreadUserTime(getId()); (in this class that extends Thread). I think we can presume some os-specific quirk that does not affect us today! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20025#discussion_r1669325187
