jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently
Jaroslav Bachorik
jaroslav.bachorik at oracle.com
Tue Jul 23 02:35:16 PDT 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/23/2013 10:25 AM, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> This looks like a tough problem as it is altogether possible that
> some of the VM daemon threads will terminate during the duration of
> the call - and if that's the case, the condition: new peak >= old
> peak + delta might not even be true. I am not a VM specialist so I
> don't know whether there can be such daemon threads that will be
> arbitrarily started and stopped by the VM - but if that happens I
> don't see how you could work around it.
As I wrote in my reply to David the offending thread is
j.u.l.LogManager$Cleaner which kicks in randomly.
This would confirm my observations that the discrepancy is always at
most one thread more than expected.
>
> 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.
>
> There are other places that seems to be prone to failures in this
> test too for instance:
>
> startThreads(...) {
>
> while(mbean.getThreadCount() < (current + count)) { ... }
>
> }
>
> If the VM can start and stop arbitrary threads then this condition
> seems dubious. There's the same kind of logic in terminateThreads.
> Not sure you can/should do anything about it though - it's just to
> point out that these steps might need to be revisited if the test
> still fails sporadically...
>
> 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.
- -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-----
More information about the serviceability-dev
mailing list