RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

[Mandy Chung]

> On May 15, 2015, at 12:09 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Updated webrev:
> 
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.1/
> 
> I have restored synchronization to modification methods, and to my interpretation of "bulk read" operations:
> 
>    * forEach
>    * replaceAll
>    * store: (synchronized(this) in store0; also, entrySet() returns a synchronizedSet)
>    * storeToXML: PropertiesDefaultsHandler.store() synchronizes on the Properties instance
>    * propertyNames(): returns an Enumeration not backed by the Properies; calls (still synchronized) enumerate()
>    * stringPropertyNames returns a Set not backed by the Properties; calls (still synchronized) enumerateStringProperties
> 
>  These continue to return a synchronized[Set|Collection]:
>    * keySet
>    * entrySet
>    * values


The enumerate and enumerateStringProperties methods calls entrySet() to enumerate all entries adding to the given map. The methods are synchronized and it can call map.entrySet directly to avoid the unnecessary synchronization. 

> 
>  These methods should operate on a coherent snapshot:
>    * clone
>    * equals
>    * hashCode
> 
>  I expect these two are only used for debugging.  I wonder if we could get away with removing synchronization:
>    * list
>    * toString
> 

list() method calls enumerate() that is synchronized to take a snapshot and it doesn’t need synchronize. It may be useful to leave toString with synchronize that we know the string is a snapshot.

Otherwise, looks good.

Mandy