I was thinking in a similar direction.
It is better to count only tested threads instead of the unreliable and
expensive retries.
Thanks,
Serguei
On 5/22/20 10:26, Alex Menkov wrote:
Hi Daniil,
I'm not sure all this retry logic is a good way.
As mentioned in jira the most important part of the testing is
ensuring that you find all the created threads when they are alive,
and you don't find them when they are dead. The actual thread count
checking is not that important.
I agree with this and I'd just simplify the test by removing checks
for thread count. VM may create and destroy internal threads when it
needs it.
--alex
On 05/18/2020 10:31, Daniil Titov wrote:
Please review the change [1] that fixes an intermittent failure of
the test.
This test creates and destroys a given number of daemon/user threads
and validates the count of those started/stopped threads against
values returned from ThreadMXBean thread counts. The problem here is
that if some internal threads is started ( e.g. "
HotSpotGraalManagement Bean Registration"), or destroyed (e.g. "JVMCI
CompilerThread ") the test hangs waiting for expected number of live
threads.
The fix limits the time the test is waiting for desired number of
live threads and in case if this limit is exceeded the test repeats
itself.
Testing. Test with Graal on and Mach5 tier1-tier7 test passed.
[1] http://cr.openjdk.java.net/~dtitov/8131745/webrev.01
[2] https://bugs.openjdk.java.net/browse/JDK-8131745
Thank you,
Daniil
