RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

[Jaroslav Bachorik]

On 13.5.2015 19:40, Martin Buchholz wrote:
> toString()should never return null, I think.

It doesn't matter much here. The test would fail with an NPE and it 
would be right to do so. None of the suppliers should ever return null.

>
>    52         @Override
>    53         public String toString() {
>    54             T resolved = val.get();
>    55             return resolved != null ? resolved.toString() : null;
>    56         }
>
>
> I expected methods like waitForCondition to include a timeout with
> failure.  I like 10 seconds, being large enough to never be hit
> spuriously in tests.

It's difficult to find a value 'large enough'. Imagine the test running 
on a small embedded device and fastdebug build. I had my fun fixing 
tests failing intermittently because it was thought that the original 
timeout was large enough. I better leave it to the harness.

>
> Why not
> () -> (long) mbean.getThreadCount(),

Because curLiveThreadCount needs to be set to mbean.getThreadCount() value.

>
>   169             ()->{
>   170                 curLiveThreadCount = mbean.getThreadCount();
>   171                 return (long)curLiveThreadCount;
>   172             },
>
>
> I worry that
> mbean.getThreadCount()
> is hard to test since the "system" may spin up and shut down utility
> threads at any time.

The 'system' threads are not reported by this method. And the current 
understanding is that once VM is fully initialized no user-observable 
threads are randomly started on behalf of the system.

-JB-

>
> On Wed, May 13, 2015 at 4:46 AM, Jaroslav Bachorik
> <jaroslav.bachorik at oracle.com <mailto:jaroslav.bachorik at oracle.com>> wrote:
>
>     On 1.5.2015 21:55, Martin Buchholz wrote:
>
>
>
>         On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
>         <jaroslav.bachorik at oracle.com
>         <mailto:jaroslav.bachorik at oracle.com>
>         <mailto:jaroslav.bachorik at oracle.com
>         <mailto:jaroslav.bachorik at oracle.com>>> wrote:
>
>              On 30.4.2015 19:18, Martin Buchholz wrote:
>
>                  Tests that sleep can almost always be better written
>         some other way.
>                  In this case, I would prefer busy-waiting with timeout
>         until the
>                  expected condition becomes true.
>
>
>              The thing is that in case of a real issue with the thread
>         counters we
>              a/ would be busy-waiting till the test times out (using an
>         arbitrary
>              delay is also problematic due to different performance of
>         different
>              machines running with different configurations)
>
>
>         Far less problematic (performance-wise and reliability-wise)
>         than the
>         fixed sleep.
>
>              b/ would get a rather confusing message about the test
>         timing out at
>              the end
>
>
>         You can easily improve the error message.
>
>
>     Well, not that easily. It is not possible to get a notification when
>     JTREG decides to timeout the test. So you will get the standard
>     JTREG message and that's all.
>
>     I was able to modify the test to wait for a given condition and
>     provide useful messages in case of mismatch and retry. For the price
>     of an increased complexity. On the other hand, the test should be
>     much more resilient to timing errors caused by slow setups.
>
>     Updated webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.01
>
>     Thanks,
>
>     -JB-
>
>