jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently

[Daniel Fuchs]

On 7/23/13 11:35 AM, Jaroslav Bachorik wrote:
> As I wrote in my reply to David the offending thread is
> j.u.l.LogManager$Cleaner which kicks in randomly.

Argh... Logging again :-)

> This would confirm my observations that the discrepancy is always at
> most one thread more than expected.

What you could do then is call:

   Logger.getLogger("foo").info("Logging initialized");

first thing in the main(). This way the Cleaner thread will
already be there and won't perturb the test.

>> There seems to be something strange in the test though: line 209,
>> you catch InterruptedException just to call
>> Thread.currentThread().interrupt() and interrupt the thread
>> again?? Did you mean maybe to call
>> Thread.currentThread().interrupted() instead?
>
> No, it checks whether the thread has been interrupted and cleans the
> interrupted flag.

That's what interrupted() will do. But interrupt() will cause the next
call to Thread.sleep() to throw InterruptedException - hence
my question.

>> Also I'm not sure that using volatile for the 'live' array will
>> work - the array itself is volatile - but does it extends to its
>> elements?
>
> No, it does not. But this code has been sitting there for some time.

Well - I'll leave it to you - but personally I would fix it along,
just to make sure the test doesn't fail because of it.

cheers,

-- daniel

>
> - -JB-
>
>>
>> It might be better to declare the live array as static final and
>> use a synchronization block on the array itself when accessing it:
>>
>> private static final boolean live[] = new boolean[ALL_THREADS];
>> private static boolean isAlive(int i) { synchronized(live) { return
>> live[i] }; }
>>
>> ...
>>
>> synchronized(live) { live[i] == false; }
>>
>> ...
>>
>> while (isAlive[id]) { ... }
>>
>> ...
>>
>> best regards,
>>
>> -- daniel
>>
>> On 7/22/13 1:55 PM, Jaroslav Bachorik wrote:
>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java
>>> test seems to be failing intermittently.
>>>
>>> The test checks the functionality of the
>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by
>>> capturing the current value of "getPeakThreadCount()", starting
>>> a predefined number of the user threads, stopping them and
>>> resetting the stored peak value and making sure the new peak
>>> equals to the number of the actually running threads.
>>>
>>> The main problem is that it is not possible to prevent JVM to
>>> start/stop arbitrary system threads while executing the test.
>>> This might lead to small variations of the reported peak (a
>>> short-lived system thread is started while the batch of the user
>>> threads is running) or the expected number of running threads
>>> (again, a short-lived system thread is started at the moment the
>>> test asks for the number of running threads).
>>>
>>> The patch does not fix those shortcomings as it is not really
>>> possible to do given the nature of the JVM threading system. It
>>> rather tries to relax the conditions while still maintaining the
>>> ability to detect functional problems - eg. decreasing peak
>>> without explicitly resetting it and reporting false number of
>>> threads.
>>>
>>> The webrev is at:
>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJR7k5UAAoJELSZyqhGiB1MsFoH/Rm/Of3/3U0hxvnB/1/PixYJ
> z1fakf98Gepyp9eIyNKZ5sfNCu6Zy+A826Uqfp/Hve8nUA5D9pzEiTpNoB4Fzts1
> CWwn+Gd8r4crXXTNKKEg1vTOUEMcmRkUujY356ndmrcdZElRMQJwdOvkwgg9Z+Tn
> l0ZJLPTDyaDUtuP5D32RZYSMxf1yXL6hXbXNiOEWm9VD4NgxPpl8b4vu0cMrRiHH
> A+anZ9nUiEhdBsTJIcqgU4bmHBM8eXEDDepBMpnK6LyM/2eDhPj3iTqQpav26Lsd
> cURgR1Tgqs36bdlUCU4Q3MqPtHfnBibTTPxphXbhzgfAGMUW5JFerYGJIvTvpAw=
> =d/Q+
> -----END PGP SIGNATURE-----
>