RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently

[serguei.spitsyn at oracle.com]

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
>>
>>
>>