<div dir="ltr">Thanks Ben. <br>I used visualVM just to compare CPU consumption between Java-11 & Java 21. <br>Definitely spending more time using profilers will help to identify the issue but Nashorn's licensing (GPL v2) and inability to create Issue/PR in github repo makes me think if its a right direction towards the resolution of the issue.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2024 at 2:50 PM Ben Evans <<a href="mailto:benjamin.john.evans@gmail.com">benjamin.john.evans@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You might try investigating further with a combination of JFR (JDK<br>
Flight Recorder, built-in to the JDK) and the GUI tool JMC (JDK<br>
Mission Control, available here: <a href="https://adoptium.net/en-GB/jmc/" rel="noreferrer" target="_blank">https://adoptium.net/en-GB/jmc/</a>)<br>
<br>
I often find it to be significantly more useful than the capabilities<br>
of VisualVM.<br>
<br>
Thanks,<br>
<br>
Ben<br>
<br>
On Fri, Oct 25, 2024 at 4:21 PM Packiaraj S <<a href="mailto:s.packiaraj@gmail.com" target="_blank">s.packiaraj@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> We use Nashorn with Tomcat as a long running service. We recently migrated to Java 21. ( from java 11 and the performance is good with Java-11).<br>
> Since Nashorn is moved out of JDK we have pulled in 'nashorn-core-15.4.jar' and its dependency (asm*) and loaded it as a regular jar. Functionality everything looks ok.<br>
><br>
> During the performance test we observed very high cpu usage when nashorn engine's 'eval' is called.  The CPU consumption is so high that instances are throttled and performance becomes 10x slower compared to java-11.<br>
><br>
> Upon investigation using profiler (jvisualVM) looks like most of the CPU is spent in compile method, more specifically during ContextCodeInstaller.initialize and NamedContextCodeInstaller.install<br>
><br>
> Looks like the compile method is optimized with cache, unfortunately the cache is in context scope, meaning it's not shared between ScriptEngines and Nashorn is not thread-safe (as per the docs) to use a single instance of ScriptEngine across all threads. Also the cache uses 'soft-reference', would it cause double whammy when there is a memory pressure.<br>
><br>
> so, how to improve the performance of the Nashorn engine, specifically the `compile` part.<br>
> Is there any other option we can try? BTW,  persistent-code-cache did not help as OptimisticTypesPersistence.getVersionDirName is performing poorly<br>
><br>
> Test code that we used to study this high CPU issue is attached.<br>
><br>
> Thanks a lot for hemp & any insight<br>
> Sakkanan<br>
</blockquote></div>