Thanks Ben. I used visualVM just to compare CPU consumption between Java-11 & Java 21. 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.
On Fri, Oct 25, 2024 at 2:50 PM Ben Evans <[email protected]> wrote: > You might try investigating further with a combination of JFR (JDK > Flight Recorder, built-in to the JDK) and the GUI tool JMC (JDK > Mission Control, available here: https://adoptium.net/en-GB/jmc/) > > I often find it to be significantly more useful than the capabilities > of VisualVM. > > Thanks, > > Ben > > On Fri, Oct 25, 2024 at 4:21 PM Packiaraj S <[email protected]> wrote: > > > > Hello, > > > > 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). > > 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. > > > > 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. > > > > Upon investigation using profiler (jvisualVM) looks like most of the CPU > is spent in compile method, more specifically during > ContextCodeInstaller.initialize and NamedContextCodeInstaller.install > > > > 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. > > > > so, how to improve the performance of the Nashorn engine, specifically > the `compile` part. > > Is there any other option we can try? BTW, persistent-code-cache did > not help as OptimisticTypesPersistence.getVersionDirName is performing > poorly > > > > Test code that we used to study this high CPU issue is attached. > > > > Thanks a lot for hemp & any insight > > Sakkanan >
