Looks good to me. Thanks!
Naoto
On 10/5/11 8:42 AM, Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
>: hg diff test/java/util/Locale/Bug6989440.java
diff -r 24741fe639a8 test/java/util/Locale/Bug6989440.java
--- a/test/java/util/Locale/Bug6989440.java Tue Oct 04 16:37:08 2011 +0100
+++ b/test/java/util/Locale/Bug6989440.java Wed Oct 05 16:34:09 2011 +0100
@@ -37,14 +37,15 @@ import sun.util.LocaleServiceProviderPoo
import sun.util.LocaleServiceProviderPool;
public class Bug6989440 {
- public static void main(String[] args) {
- TestThread t1 = new TestThread(LocaleNameProvider.class);
- TestThread t2 = new TestThread(TimeZoneNameProvider.class);
- TestThread t3 = new TestThread(DateFormatProvider.class);
-
- t1.start();
- t2.start();
- t3.start();
+ public static void main(String[] args) throws Exception {
+ Thread[] threads = new Thread[3];
+ threads[0] = new TestThread(LocaleNameProvider.class);
+ threads[1] = new TestThread(TimeZoneNameProvider.class);
+ threads[2] = new TestThread(DateFormatProvider.class);
+ for (int i=0; i<threads.length; i++)
+ threads[i].start();
+ for (int i=0; i<threads.length; i++)
+ threads[i].join();
}
-Chris.
On 05/10/2011 15:57, Naoto Sato wrote:
Hi Chris,
I appreciate it, and will fix the test case.
Naoto
On 10/5/11 7:07 AM, Chris Hegarty wrote:
Alan, David,
I noticed CR 7027061 was closed as 'not a defect'. Should I file a new
CR to have the jtreg test fixed (join on all created threads)? The test
will still exercise what it is supposed to, and the
ConcurrentModificationException issue can be investigated at another
time. This way we can get more stable test runs.
-Chris.
On 04/10/2011 17:04, David Holmes wrote:
Thanks Chris and Alan.
On 4/10/2011 11:24 PM, Alan Bateman wrote:
Chris Hegarty wrote:
Trivially, should the main thread in the test be waiting on the three
other threads to complete before exiting?
I think jtreg will try to cleanup once the main thread completes. The
main thread should keep an array of the threads it creates and invoke
join() on each of them before returning from main. We do this all the
time in other areas.
Right, once the main thread completes then jtreg will attempt to
cleanup
the remaining non-daemon threads in the thread group. It does this by
interrupting each of the remaining threads in a loop up to a maximum
number of rounds or until the remaining threads have terminated.
I wasn't aware of this behaviour from jtreg (but then I don't write
such
tests). It explains the jtreg "error". I expect the test threads are
not
responsive to interrupts (why should they be).
The reported ConcurrentModificationException would indicate a potential
issue still remaining in the locale code.
David
It's
possible that if the test is changed up to join on each of the 3
threads
that this intermittent failure will go away. If so, then it
suggests to
me that perhaps the interrupt is causing a side effect that causes one
of the threads to go into a loop block uninterruptedly. This is just a
guess of course and it requires digging into the Locale code to
come up
with specific theories.
-Alan.
