[jira] [Commented] (RIVER-396) PreferredClassProvider classloader cache concurrency improvement

["Hudson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424325#comment-13424325 ] 

Hudson commented on RIVER-396:
------------------------------

Integrated in River-trunk-jdk7 #57 (See [https://builds.apache.org/job/River-trunk-jdk7/57/])
    River-396 PreferredClassProvider Concurrency improvement.  Re-factored and simplified the weak cache, which was a little difficult to understand due to the relations between weak references and WeakHashMap.

WeakHashMap uses weak keys but what we really wanted was a ConcurrentMap that used weak values, where the value is a child ClassLoader, the key is unique to the ClassLoader so when it becomes weakly reachable the key can be removed too.

using a ConcurrentMap also eliminates any issue with synchronisation and atomic replacement of a key & value combination that has become weakly reachable.  This allows removal of the synchronised block around checking ClassLoader permissions, Concurrency in practise recommends against synchronising on external state.

Tests have been revised to include the classpath and permissions for the new libraries. (Revision 1366641)

     Result = SUCCESS
                
> PreferredClassProvider classloader cache concurrency improvement
> ----------------------------------------------------------------
>
>                 Key: RIVER-396
>                 URL: https://issues.apache.org/jira/browse/RIVER-396
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_loader
>    Affects Versions: River_2.1.2
>            Reporter: Chris Dolan
>            Priority: Minor
>             Fix For: River_2.2.0
>
>         Attachments: PreferredClassProvider.java.patch
>
>
> 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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira