[
https://issues.apache.org/jira/browse/SLING-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596577#comment-16596577
]
Jörg Hoh commented on SLING-7207:
---------------------------------
Hi Radu,
when we did performance tests about 2 years ago with an application, which is
heavily relying on HTL rendered pages, we found in the profiler, that we ran
into lock contention in sightly when resolving the methods of the sling model
(a very common model which is used on many pagse, sometimes even multiple
times). A common stacktrace looked like this:
{noformat}
3XMTHREADINFO "172.23.175.22 [1447673771100] GET /content/myapp/home.html
HTTP/1.1" J9VMThread:0x00000000047DCD00, j9thread_t:0x00007FFFA5E6E660,
java/lang/Thread:0x00000002CA45C768, state:B, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0x3E5BE, isDaemon:true)
3XMTHREADINFO1 (native thread ID:0x14E1C, native priority:0x5,
native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201)
3XMTHREADINFO2 (native stack address range from:0x00007FFEF36EB000,
to:0x00007FFEF372C000, size:0x41000)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at
java/util/Hashtable.get(Hashtable.java:617(Compiled Code))
4XESTACKTRACE at
java/lang/Class.lookupCachedMethods(Class.java:2925(Compiled Code))
4XESTACKTRACE at
java/lang/Class.getMethods(Class.java:1136(Compiled Code))
4XESTACKTRACE at
org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.findMethod(RenderContextImpl.java:355(Compiled
Code))
4XESTACKTRACE at
org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.getObjectNoArgMethod(RenderContextImpl.java:345(Compiled
Code))
4XESTACKTRACE at
org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.getObjectProperty(RenderContextImpl.java:323(Compiled
Code))
4XESTACKTRACE at
org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.getProperty(RenderContextImpl.java:281(Compiled
Code))
4XESTACKTRACE at
org/apache/sling/scripting/sightly/impl/engine/runtime/RenderContextImpl.resolveProperty(RenderContextImpl.java:103(Compiled
Code))
4XESTACKTRACE at
apps/myapp/mypage/navigation/SightlyJava_navigation$1.render(SightlyJava_navigation.java:177(Compiled
Code))
{noformat}
We observed this under IBM JDK 7, 10 CPU cores and a lot of concurrent
requests. At the moment we intend to switch to IBM JDK8 (plus newer libraries),
but we haven't conducted these tests again.
What JVM were you using in your performance test? Have you tried it with IBM
JDK as well? I would be very happy if you could test it or provide me the
testcase, so I can execute it on our systems. I would also like to increase the
concurrency to a very high level to find out if this concurrency issue we
observed still persists.
Thanks,
Jörg
> Get rid of runtime reflection in HTL expression evaluation
> ----------------------------------------------------------
>
> Key: SLING-7207
> URL: https://issues.apache.org/jira/browse/SLING-7207
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
> Affects Versions: Scripting HTL Engine 1.0.20, Scripting HTL Compiler
> 1.0.0, Scripting HTL Java Compiler 1.0.0
> Reporter: Vlad Bailescu
> Assignee: Radu Cotescu
> Priority: Major
>
> At the moment the following expression
> {code}
> <sly data-sly-use.obj="com.my.Obj">${obj.message}</sly>
> {code}
> generates this Java code:
> {code}
> Object _global_obj = null;
> _global_obj = renderContext.call("use", "com.my.Obj", obj());
> {
> Object var_0 = renderContext.call("xss",
> renderContext.getObjectModel().resolveProperty(_global_obj, "message"),
> "text");
> out.write(renderContext.getObjectModel().toString(var_0));
> }
> {code}
> Resolving the property is done via reflection at runtime. Given the fact that
> for most use providers (JS is an exception) we know the type of
> {{_global_obj}} we could determine the right method to call at compile time.
> Resulting code might look something like:
> {code}
> com.my.Obj _global_obj = renderContext.call("use", com.my.Obj.class, obj());
> {
> Object var_0 = renderContext.call("xss", _global_obj.getMessage()),
> "text");
> out.write(renderContext.getObjectModel().toString(var_0));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
