High CPU consumption with Java-21 + Nashorn 15.4

[Rony G. Flatscher]

Just a somewhat "crazy" idea: it seems you are well acquainted with the details and if it turns out 
that Nashorn is not viable, how about trying to use JavaFX WebKit's JavaScript instead for your 
purposes? You may be able to implement a ScriptEngine for it that could better serve your needs?

You could check out the documentation of the JavaFX module javafx.web and take a look at its 
javafx.scene.web.WebEngine class as it documents its interfaces to JavaScript (note that this 
implementation mandates that WebEngine objects are created and accessed on the JavaFX 
Application/GUI thread only).

If exploring that route, maybe the first thing to do is to ask about the viability of such an 
approach on the javafx mailing list (openjfx-dev mailing list of openjdk.org) first?

---rony


On 26.10.2024 00:45, Packiaraj S wrote:
> 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/20241026/f9772ab4/attachment.htm>