[RIVER-396] PreferredClassProvider classloader cache concurrency improvement

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: River_2.1.2
• Fix Version/s: River_2.2.0
• Component/s: net_jini_loader
• Assignee: Unassigned
• Reporter: Chris Dolan
• Created: 13/Apr/11 19:03
• Updated: 28/Jul/12 12:09
• Resolved: 13/Jun/11 05:46

Description

The PreferredClassProvider.lookupLoader() method uses a single coarse lock to synchronize its cache of ClassLoader instances. Because the creation of a ClassLoader can be an expensive operation (including remote calls in some special cases) this global lock can be a significant bottleneck.

Attached is a patch to refactor that code to hold only a finer grained lock while constructing the ClassLoader in case of a cache miss. The refactor moves the ReferenceQueue field out of any synchronized block, because that class is already thread-safe. The refactor still holds a coarse lock while checking the cache, but holds only a finer lock (per cache line) while checking and possibly creating the ClassLoader.

See also RIVER-336 where an alternative version of this patch was proposed. But a following analysis revealed concurrency problems with that patch: http://mail-archives.apache.org/mod_mbox/river-dev/201104.mbox/browser