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

[Mandy Chung]

On 05/11/2015 11:41 PM, Peter Levart wrote:
>
>
> 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);
>


How likely does existing code do this?  A proper way is to call 
System.setProperty.  One pattern I found on System.setProperties is like 
this to add a system property of key/value pair:

Properties props = System.getProperties();
props.put(key, value);
System.setProperties(props);

More investigation needs to be done (e.g. look at System.setProperties 
and other system property related APIs and any spec change is needed to 
be made and the compatibility implication) if we agree that it worths 
keeping this change local to system properties.

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

Perhaps the spec of System.setProperties should be changed (I don't have 
cycle to think through this).

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

I agree that making read-only methods not synchronized while keeping any 
method with write-access with synchronized is pretty safe change and low 
compatibility risk.  On the other hand, would most of the overrridden 
methods be synchronized then?

Mandy