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-----
