commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Ernst (JIRA)" <>
Subject [jira] Updated: (EL-5) [el] Contention on global cache / parseExpression
Date Fri, 26 May 2006 13:15:30 GMT
     [ ]

Matthias Ernst updated EL-5:

    Attachment: patch-el-cache.txt

I have stumbled over this again. The synchronized map proves to be a point of contention in
an application that runs on a highly concurrent machine (Sun T2000 w/32 cores) with JSPs that
contain many EL expressions. Several hundred hits/s times several ten expressions/JSP leads
to several (ten) thousand ELuations per second.

The simplest patch that could possibly work is as follows: instead of using a mutable, synchronized
hashmap, use an immutable, copy-on write table where only the access to the cache field itself
is protected through a monitor. A corresponding patch is attached.

[With Java 5, this monitor-protected field could even be replaced through a volatile field.
Doing so is legal under the revised memory model and produced even more throughput in my non-trivial

> [el] Contention on global cache / parseExpression
> -------------------------------------------------
>          Key: EL-5
>          URL:
>      Project: Commons EL
>         Type: Bug

>     Versions: 1.0 Final
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Matthias Ernst
>  Attachments: patch, patch-el-cache.txt
> The ExpresssionEvaluatorImpl maintains a static synchronized hashmap as a global
> parser cache. In my tests, this proves to be a contention point in highly
> concurrent web access, even if the cache is already filled:
> "tcpConnection-8080-514" daemon prio=1 tid=0x08214890 nid=0x4e39 waiting for
> monitor entry [bd9ff000..bd9ff908]
>         at java.util.Collections$SynchronizedMap.get(
>         - waiting to lock <0x45586ef0> (a java.util.Collections$SynchronizedMap)
>         at
> org.apache.commons.el.ExpressionEvaluatorImpl.parseExpressionString(
> ...
> Even pre-parsing the expressions through #parseExpression doesn't help: it
> parses the expression for syntactic correctness and returns an instance of
> JSTLExpression that, however, doesn't contain the parsing result. It is reparsed
> on every evaluation.
> I propose
> * evaluator instance local caches that still need synchronization, but can be
> made thread-local, page-local oder whatever by the calling application / container.
> * to actually maintain the parsing result in JstlExpression
> I would volunteer to develop the respective patches, if desired.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message