I don't think this approach adds any value to test coverage.
We have other tests which are targeted to test the methods.
IMO the test can still test the methods, but with relaxed conditions.
maybe something like
1. at the beginning:
getTotalStartedThreadCount() >= 1,
getThreadCount() >= 1
getPeakThreadCount() >= 1
2. when threads are alive:
getTotalStartedThreadCount() >= ALL_THREADS + value from step 1,
getThreadCount() >= 1 + ALL_THREADS
getPeakThreadCount() >= 1 + ALL_THREADS
3. after the threads terminates:
getThreadCount() >= 1
getTotalStartedThreadCount() and getPeakThreadCount() >= values at step 2
--alex
On 05/22/2020 10:51, Daniil Titov wrote:
Hi Alex,
I was thinking about it as well. But the test also indirectly tests
getTotalStartedThreadCount(), getThreadCount(), and getPeakThreadCount()
methods of ThreadMXBean. So I tried to not reduce the test coverage.
Best regards,
Daniil
On 5/22/20, 10:26 AM, "Alex Menkov" <alexey.men...@oracle.com> 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
>
>
>
