David,
Expanding (more threads and more runs) and running this test on one of
our dual core Linux x64 boxes, reproduce the CME about one in every ten
runs.
I instrumented where the CME was being created to determine the
expected/actual modcount:
final void checkForComodification() {
if (modCount != expectedModCount)
- throw new ConcurrentModificationException();
+ throw new ConcurrentModificationException("Expected: "
+ expectedModCount +
+ ", got: " +
modCount);
I see several exceptions, similar to the following (numbers vary):
Exception in thread "Thread-23"
java.util.ConcurrentModificationException: Expected: 96, got: 156
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819)
at java.util.ArrayList$Itr.next(ArrayList.java:791)
at java.util.AbstractCollection.addAll(AbstractCollection.java:333)
at java.util.HashSet.<init>(HashSet.java:117)
at
sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206)
at Interrupter$TestThread.run(Interrupter.java:49)
There would appear to be 156 JRE Locales ( at least on this system ),
modCount is incremented for each add(), but when the iterator is created
( implicitly during the HastSet.addAll ) it sees a different value for
modCount.
I think there is a visibility issue here. availableJRELocales is
volatile, but the List reference returned from getJRELocales is not. In
the case where availableJRELocales is not null there will be no memory
barrier to force a HB relationship. Or maybe I've gotten this wrong? His
is quite bizarre, or maybe it is just the overly complicated use of
locking/DCL in this class.
-Chris.
On 10/ 5/11 07:01 PM, David Holmes wrote:
This might not be related to the CME problem, but here:
public static LocaleServiceProviderPool getPool(Class<? extends
LocaleServiceProvider> providerClass) {
LocaleServiceProviderPool pool = poolOfPools.get(providerClass);
if (pool == null) {
LocaleServiceProviderPool newPool =
new LocaleServiceProviderPool(providerClass);
pool = poolOfPools.put(providerClass, newPool);
if (pool == null) {
pool = newPool;
}
}
return pool;
}
we should probably be using poolOfPools.putIfAbsent(providerClass, newPool)
David
On 6/10/2011 3:35 AM, Naoto Sato wrote:
I will look into this. Reopened the original CR.
Naoto
On 10/5/11 9:58 AM, Alan Bateman wrote:
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!
I assume there is also some underlying issue in the Locale code and this
might get hidden if we fix the test (I"ve no objection to fixing the
test of course, just thinking that we should study the Locale code to
try to identify the deadlock or hang or whatever it is that is causing
the threads in this test not to terminate).
-Alan
