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

[Martin Buchholz]

(drive by commenting)

 100             Thread thread = new MyThread(i);
 101             allThreadIds.add(thread.getId());
 102             allThreads[i] = thread;
 103             allThreads[i].setDaemon(i < DAEMON_THREADS);
 104             allThreads[i].start();

I'm surprised there's a new local "thread" but it didn't get used in
all the places it could.

 113         // Check mbean now. All threads must appear in
getAllThreadIds() list
 114         long[] list = mbean.getAllThreadIds();

The double loop here is mostly just doing a containsAll.  I would
create 2 Collections of threads (we've already done one!) and then use
containsAll, for much greater clarity.

On Fri, May 29, 2020 at 4:30 PM Daniil Titov <daniil.x.titov at oracle.com> wrote:
>
> Hi Alex and Serguei,
>
> Please review a new version of the change [1] that makes sure that the test counts
> only the threads it creates and ignores  Internal threads VM might create or  destroy.
>
> Testing: Running this test in Mach5 with Graal on several hundred times ,
>  tier1-tier3 tests  are in progress.
>
> [1] http://cr.openjdk.java.net/~dtitov/8131745/webrev.02/
> [2] https://bugs.openjdk.java.net/browse/JDK-8131745
>
> Thank you,
> Daniil
>
> On 5/22/20, 10:26 AM, "Alex Menkov" <alexey.menkov at 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
>     >
>     >
>     >
>
>