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

[David Holmes]

On 13/05/2015 9:46 PM, Jaroslav Bachorik 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>>
>> 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

Certainly increased complexity - took me quite a while to figure out 
what it all meant. :) waitForCondition should be waitTillEqual as that 
is the only condition checked (unless you'd like to make it more complex 
and pass in a Predicate ;-) ).

I think the Thread.yield would be better as a short sleep

Thanks,
David
-----


> Thanks,
>
> -JB-