gt; Serguei
>
> > --Best regards,
> > Daniil
> >
> > From: "serguei.spit...@oracle.com"
> > Date: Thursday, June 4, 2020 at 3:03 PM
> > To: Daniil Titov , Alex Menkov
, serviceabil
> --Best regards,
> Daniil
>
> From: "serguei.spit...@oracle.com"
> Date: Thursday, June 4, 2020 at 3:03 PM
> To: Daniil Titov , Alex Menkov
, serviceability-dev
> Subject: Re: RFR: 8131745:
java/lang/management/ThreadMXBean/
he diff value is
calculated at line 203.
I'm sorry, if the same questions are repeated again.
Thanks,
Serguei
> --Best regards,
> Daniil
>
> From: "serguei.spit...@oracle.com"
> Date: Thursday, June 4, 2020 at 3:03 PM
> To: Daniil Titov
8131745: java/lang/management/ThreadMXBean/AllThreadIds.java
still fails intermittently
Hi Daniil,
It is hard to be on top of all the details in these review rounds.
When all threads are counted with mbean.getThreadCount() it is not clear
there is no race with new non-tested threads creation. I
-dev
Subject: Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java
still fails intermittently
Hi Daniil,
It is hard to be on top of all the details in these review rounds.
When all threads are counted with mbean.getThreadCount() it is not clear
there is no race with new non-tes
Hi Daniil,
It is hard to be on top of all the details in these review rounds.
When all threads are counted with mbean.getThreadCount()
it is not clear
there is no race with new non-tested threads creation. Is it
possible?
If so, then the check
Hi Daniil,
LGTM.
--alex
On 06/03/2020 20:42, Daniil Titov wrote:
Hi Alex,
Please review a new version of the webrev [1] that no longer uses
waitTillEquals() method.
[1] http://cr.openjdk.java.net/~dtitov/8131745/webrev.04/
[2] https://bugs.openjdk.java.net/browse/JDK-8131745
Thank you,
Hi Alex,
Please review a new version of the webrev [1] that no longer uses
waitTillEquals() method.
[1] http://cr.openjdk.java.net/~dtitov/8131745/webrev.04/
[2] https://bugs.openjdk.java.net/browse/JDK-8131745
Thank you,
Daniil
On 6/3/20, 4:42 PM, "Alex Menkov" wrote:
Hi again Daniil,
Hi again Daniil,
On 06/03/2020 16:31, Daniil Titov wrote:
Hi Alex,
Thanks for this suggestion. You are right, we actually don't need this
waitForAllThreads() method.
I will include this change in the new version of the webrev.
207 int diff = numNewThreads -
Hi Alex,
Thanks for this suggestion. You are right, we actually don't need this
waitForAllThreads() method.
I will include this change in the new version of the webrev.
> 207 int diff = numNewThreads - numTerminatedThreads;
> 208 long threadCount =
Hi Daniil,
couple notes:
198 waitForThreads(numNewThreads, numTerminatedThreads);
You don't actually need any wait here.
Test cases wait until all threads are in desired state
(checkAllThreadsAlive uses startupCheck, checkDaemonThreadsDead and
checkAllThreadsDead use join())
205
Hi Alex, Serguei, and Martin,
Thank you for your comments. Please review a new version of the fix that
addresses them, specifically:
1) Replaces a double loop in checkAllThreadsAlive() with a code that uses
collections and containsAll() method.
2) Restores the checks for other ThreadMXBean
Hi Daniil,
1. before the fix checkLiveThreads() tested
ThreadMXBean.getThreadCount(), but now as far as I see it tests
Thread.getAllStackTraces();
2.
237 private static void checkThreadIds() throws InterruptedException {
238 long[] list = mbean.getAllThreadIds();
239
240
Hi Daniil,
LGTM.
Thanks,
Serguei
On 5/29/20 16:28, Daniil Titov 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
(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
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
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
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
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" wrote:
Hi
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
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
21 matches
Mail list logo
