High CPU consumption with Java-21 + Nashorn 15.4

[Packiaraj S]

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 <benjamin.john.evans at gmail.com>
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 <s.packiaraj at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nashorn-dev/attachments/20241025/e1f3b2f7/attachment.htm>