RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java (original) (raw)

Mandy Chung mandy.chung at oracle.com
Tue May 12 20:49:18 UTC 2015

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

More information about the core-libs-dev mailing list