[ 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)