[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently
From:       Martin Buchholz <martinrb () google ! com>
Date:       2020-05-30 16:11:32
Message-ID: CA+kOe08Y_hi5HQ-fQWsWgyfxv+meZd92J=Rvu-EbGg9nS7Yv2A () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]