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

Daniel Fuchs daniel.fuchs at oracle.com
Wed May 6 10:06:17 UTC 2015

On 06/05/15 11:41, David Holmes wrote:

I don't think you want to de-synchronize the load* methods - you don't want two threads calling load concurrently. But that then raises the problem of concurrent modification while a load is in progress. Synchronization ensures serialization and by removing it you have done more than just avoid deadlocks.

I think this needs a more careful examination of the expected/desired concurrent interactions between different methods. It may be that simply not utilizing the synchronized Hashtable methods is sufficient to resolve the deadlock, while still providing reasonable serialization via the existing synchronized Properties methods - or it may not. But allowing concurrent modifications will change behaviour in an unexpected, and incompatible way, in my opinion. David ----- Hi David, You say: "It may be that simply not utilizing the synchronized Hashtable methods is sufficient to resolve the deadlock, while still providing reasonable serialization via the existing synchronized Properties methods - or it may not". How do you propose to not utilize synchronized Hashtable methods? By not utilizing Properties at all? This may be difficult to achieve as most system configuration is specified as system Properties. What I meant was to continue to delegate to the CHM to replace the inherited Hashtable methods, but to keep the synchronized on the Properties specific methods.

What about changing load0 to return a plain HashMap? Then you could transfer the HashMap content into the CHM in one go - that's the only part that really needs to be protected against concurrent modification, isn't it?

The PropertiesDefaultHandler could also be changed to use an intermediate HashMap object as well.

There would be a small compatibility issue however if some subclass of Properties has some special logic for the case where a property is declared twice (for instance, if it overrides put() to merge values)...

best regards,

-- daniel

More information about the core-libs-dev mailing list