Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5DBEC751E for ; Wed, 12 Oct 2011 17:29:34 +0000 (UTC) Received: (qmail 75554 invoked by uid 500); 12 Oct 2011 17:29:34 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 75459 invoked by uid 500); 12 Oct 2011 17:29:33 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 75451 invoked by uid 99); 12 Oct 2011 17:29:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 17:29:33 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 17:29:32 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 0D7C83056A5 for ; Wed, 12 Oct 2011 17:29:12 +0000 (UTC) Date: Wed, 12 Oct 2011 17:29:12 +0000 (UTC) From: "Daniel Pitts (Commented) (JIRA)" To: issues@commons.apache.org Message-ID: <1507316997.5723.1318440552056.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <872907710.17472.1315239251255.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125984#comment-13125984 ] Daniel Pitts commented on OGNL-20: ---------------------------------- I've just now gone over the branch, and have a couple of suggestions. First suggestion is ditch the ClassCacheEntryFactory interface, it doesn't do anything useful, and prevents people from supplying CacheEntryFactory, ...> in its stead. Also, CacheEntryFactory instances are intended to be flyweights, where you've actually been instantiating them every time you need them. For example, I suggest refactoring getConstructors... First, move the factory to private static final instance: {code:title=Singleton constructor factory} private static final CacheEntryFactory, List>> CONSTRUCTOR_FACTORY = new CacheEntryFactory, List>>( ) { public List> create( Class key ) throws CacheException { return Arrays.asList(key.getConstructors()); } }; {code} Then simplify the getConstructors methods: {code:title=Simplified getConstructors method} public static List> getConstructors( final Class targetClass ) throws OgnlException { return _constructorCache.get( targetClass, CONSTRUCTOR_FACTORY); } {code} Also, if you do it this way, the factory object can be added directly to the cache object, so you would actually only need _constructorCache.get(targetClass), which would delegate to get(targetClass, defaultFactory). That's my first round of advice, I'll look at it a bit more and see if there is anything else I can suggest. > Performance - Replace synchronized blocks with ReentrantReadWriteLock > --------------------------------------------------------------------- > > Key: OGNL-20 > URL: https://issues.apache.org/jira/browse/OGNL-20 > Project: OGNL > Issue Type: Improvement > Environment: ALL > Reporter: Greg Lively > Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch > > > I've noticed a lot of synchronized blocks of code in OGNL. For the most part, these synchronized blocks are controlling access to HashMaps, etc. I believe this could be done far better using ReentrantReadWriteLocks. ReentrantReadWriteLock allows unlimited concurrent access, and single threads only for writes. Perfect in an environment where the ratio of reads is far higher than writes; which is typically the scenario for caching. Plus the access control can be tuned for reads and writes; not just a big synchronized{} wrapping a bunch of code. -- 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