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

[Peter Levart]

On 05/12/2015 07:41 AM, Peter Levart wrote:
>>> Taking another look at this deadlock issue and the compatibility
>>> concerns, I wonder if we should keep this change as a special
>>> implementation for system properties rather than having this change to
>>> java.util.Properties class.  Properties is a Hashtable which specifies
>>> the fast-fail behavior (throwing ConcurrentModificationException for
>>> concurrent update).  There are other issues specific to system
>>> properties we want to clean up (e.g. read-only system property, private
>>> system property to JDK but not visible to public etc).
>>>
>>> Any thought?
>>
>> I like this idea, too. :)
>>
>> One thought:
>> In the current fix, clone() and serialization make use of 
>> package-private methods.  This could present some difficulties if 
>> system properties would use its own Properties subclass that would 
>> live outside java.util.
>>
>> -Brent
>
> Do you have an example where you would like to access/override one of 
> those methods? They are designed to be a private contract between 
> Properties and Hashtable.
>
> Regards, Peter

Ah, I understand Mandy now. You are talking about using special 
Properties implementation just for system properties. Unfortunately, 
this is currently valid code:

Properties props = new Properties();
...
System.setProperties(props);
...
props.setProperty(key, value);
assert System.getProperty(key).equals(value);

By current semantics, the props object must be installed as new system 
properties by reference, so later changes to it must be visible. Here, 
the class of system properties is chosen by user.

But I think it should be pretty safe to make the java.util.Properties 
object override all Hashtable methods and delegate to internal CMH so that:
- all modification methods + all bulk read methods such as 
(keySet().toArray, values.toArray) are made synchronized again
- individual entry read methods (get, containsKey, ...) are not 
synchronized.

This way we get the benefits of non-synchronized read access but the 
change is hardly observable. In particular since external 
synchronization on the Properties object makes guarded code atomic like 
it is now and individual entry read accesses are almost equivalent 
whether they are synchronized or not and I would be surprised if any 
code using Properties for the purpose they were designed for worked any 
differently.

Regards, Peter