On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes <dhol...@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.
>
> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java
> line 30:
>
>> 28: * non-null string for a blocked thread and then makes repeated calls
>> 29: * to getThreadInfo() and ThreadInfo.getLockOwnerName() until the
>> thread
>> 30: * has exited.
>
> Extra space before has.
Fixed.
> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java
> line 33:
>
>> 31: * @requires vm.jvmti
>> 32: * @library /test/lib
>> 33: * @compile getLockOwnerName.java
>
> You don't need a @compile statement for the current test file
Deleted.
> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java
> line 137:
>
>> 135: }
>> 136:
>> 137: System.exit(run(timeMax, System.out) + exit_delta);
>
> jtreg tests don't use System.exit!
Hmmm... that's generally true, but this is a test that must be run as
"othervm" so this style of exit with the "+ exit_delta" logic has been
used for these kinds of stress tests. I think this style came from the
VMTestbase tests and I've used it with other stress tests.
> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java
> line 189:
>
>> 187: while (testState != TS_BLOCKER_RUNNING) {
>> 188: try {
>> 189: barrierLaunch.wait(0); // wait until it is
>> running
>
> Nit: we use wait() rather than wait(0)
I fixed it in 5 places.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3478
