Am 03.02.2016 um 16:48 schrieb Rainer Jung:
Hi there,
ELParser has a field named jj_ls of type LookaheadSuccess which extends
Error. It is created during each instantiation of an ELParser object.
Creating an Error is quite slow, because e.g. it calls
java.lang.Throwable.fillInStack() during init.
...
I noticed this situation because I'm doing a performance analysis of an
application. I wonder whether creating this jj_ls for each new ELParser
instance in advance is the right thing to do. One could also put the
burden on the usage side, e.g. generating it when it is needed to be
thrown. Unfortunately I don't know enough about the typical runtime
details of ELParser. E.g. it might be that typically only few instances
of it are created because they get reused (which doesn't seem to be the
case, we only create and use it method local in
createNodeInternal.createNodeInternal()) or their results get cached
(which seems to be the case).
I'll have a look at how effective the caching is for the application in
question, but I'd be interested if there is an opinion whether the
pattern to create the Error object eagerly when creating the ELParser
object seems appropriate. No idea currently, how one would change it
though, because it is generated code.
Update: The case in question was triggered by an app having a big number
of EL expressions, about 25.000. So this could be handled by increasing
the org.apache.el.ExpressionBuilder.CACHE_SIZE.
To me it looks like the current ConcurrentCache code, which moves every
item from the first level cache "eden" to the second level cache
"longterm" when "eden" is full, is simple, but probably often not very
effective. Since longterm is a WeakHashMap I would expect the entries in
"logterm" to get destroyed quickly after the page is done. So once your
cache size gets to small, I expect more or less the cache to behave as
being completely purged. Then it starts to fill up again (and get more
effective) until the same pattern hits. So I don't expect a big use of
"longterm" depending on your GC rate and eden size. If you are lucky,
some stuff from "longterm" gets promoted to tenured and might live
longer there, but it could well be, that "longterm" dies quickly in the
young generation.
I don't have a better and simple alternative pattern at hand. It could
be interesting to make the current "eden" cache size retrievable via
JMX, but unfortunately it seems size() can be an expensive operation for
a ConcurrentHashMap under contended conditions. Not sure, whether we
should expose it, because then it will be called fir each monitoring cycle.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
