commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Pitts (JIRA)" <>
Subject [jira] [Updated] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
Date Sat, 10 Sep 2011 18:35:08 GMT


Daniel Pitts updated OGNL-20:

    Attachment: Bench Results.txt

New approach to caching with benchmarks.

I've created a few classes which I think can improve both the code design and the concurrency
of the caches used in OgnlRuntime.

It would require a refactor to use them (which I would provide if this approach is agreed

I've attached a "patch", which doesn't actually change any Ognl code, but provides implementations
of this new approach, as well as a benchmark to test the efficiency of the different approaches.

Also attached is the output of that bench mark on my machine.  It seems to clearly point to
"ConcurrentHashMap" as the winner.  Please feel free to critique my benchmark code.  If all
seems well, I'll work on JavaDocs, unit tests, and refactoring OgnlRuntime to use this new
caching approach.

> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>                 Key: OGNL-20
>                 URL:
>             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.
For more information on JIRA, see:


View raw message