P4
JhsdbThreadInfoTest.java uses "jhsdb jstack" to dump the stack of all threads. Individual thread stacks look like the following:
"Reference Handler" #2 daemon prio=10 tid=0x00007f51602ec000 nid=0x237 waiting on condition [0x00007f5144a91000]
java.lang.Thread.State: RUNNABLE
JavaThread state: _thread_blocked
- java.lang.ref.Reference.waitForReferencePendingList() @bci=0 (Interpreted frame)
- java.lang.ref.Reference.processPendingReferences() @bci=0, line=241 (Interpreted frame)
- java.lang.ref.Reference$ReferenceHandler.run() @bci=0, line=213 (Interpreted frame)
One thing the test checks for is that there is a thread with the word "daemon" followed by prio=<n>, like in the thread above. While working on the loom project I notice a couple of shortcoming in this test.
In loom there is an SA bug that causes "deamon" not to appear. The test detects this and throws a RuntimeException, but then rethrows the RuntimeException as an Error. This causes mach 5 to not detect the reason for the failure, and therefore not show anything in the "reason" column. The test should use the same template error handling approach we have in other tests.
The other issue is that if SA for some reason cannot get the priority of the thread (it can't in Loom), it prints "prio=0". 0 is not a legal priority (it should be 1 to 10), so the test should detect this failing by making sure that "prio=0" is not in the output.
"Reference Handler" #2 daemon prio=10 tid=0x00007f51602ec000 nid=0x237 waiting on condition [0x00007f5144a91000]
java.lang.Thread.State: RUNNABLE
JavaThread state: _thread_blocked
- java.lang.ref.Reference.waitForReferencePendingList() @bci=0 (Interpreted frame)
- java.lang.ref.Reference.processPendingReferences() @bci=0, line=241 (Interpreted frame)
- java.lang.ref.Reference$ReferenceHandler.run() @bci=0, line=213 (Interpreted frame)
One thing the test checks for is that there is a thread with the word "daemon" followed by prio=<n>, like in the thread above. While working on the loom project I notice a couple of shortcoming in this test.
In loom there is an SA bug that causes "deamon" not to appear. The test detects this and throws a RuntimeException, but then rethrows the RuntimeException as an Error. This causes mach 5 to not detect the reason for the failure, and therefore not show anything in the "reason" column. The test should use the same template error handling approach we have in other tests.
The other issue is that if SA for some reason cannot get the priority of the thread (it can't in Loom), it prints "prio=0". 0 is not a legal priority (it should be 1 to 10), so the test should detect this failing by making sure that "prio=0" is not in the output.