RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java

[Kevin Walls]

On Mon, 8 Jul 2024 18:13:33 GMT, Chris Plummer <cjplummer at 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