(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.ti...@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.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 > > > > > > > >
