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

[Daniel Fuchs]

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