RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]

Chris Plummer cjplummer at openjdk.java.net
Fri May 14 04:48:35 UTC 2021


On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
>> 
>> Currently running the new test thru Mach5 Tier[1-7].
>> I've run the test thru several 12 hour runs on my MBP13 and
>> on my Linux-X64 server.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop exit_delta and the VMTestbase style of exiting on test failure.

Overall it looks good. Some minor suggestions, most of which can be ignored if you wish.

Is there a reason these tests were not placed under `test/jdk/java/lang/management`?

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70:

> 68: //
> 69: 
> 70: public class getLockOwnerName {

Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150:

> 148:         System.err.println("where:");
> 149:         System.err.println("    -p       ::= print debug info");
> 150:         System.err.println("    time_max ::= max looping time in seconds");

`::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324:

> 322: 
> 323:         //
> 324:         // Launch the blocker thread:

The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329:

> 327:         // - releases threadLock
> 328:         //
> 329:         if (getName().equals("blocker")) {

Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3478


More information about the hotspot-runtime-dev mailing list