High CPU consumption with Java-21 + Nashorn 15.4

[forax at univ-mlv.fr]

> From: "Attila Szegedi" <szegedia at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Packiaraj" <s.packiaraj at gmail.com>, "nashorn-dev" <nashorn-dev at openjdk.org>
> Sent: Friday, November 1, 2024 9:37:56 PM
> Subject: Re: High CPU consumption with Java-21 + Nashorn 15.4

> Hi Remi,
> We had a similar discussion[0] almost exactly 4 years ago – the main problem was
> that the hidden classes are hidden, so JavaScript errors won't have stack
> traces anymore… We didn't get an option for a "visible hidden" class since. In
> any case, I suspect the performance difference is mostly in verification, which
> Unsafe.defineAnonymousClass didn't run, but I'm fairly sure defineHiddenClass
> does.

> Regardless, using a single ScriptEngine mostly remedies the issue. I would still
> love to get a VISIBLE ClassOption for the hidden classes tho'.

Let's prentend my memory is ok, 2020 was a special year :) 

I think we should try to ask for the VISISBLE classOption again. 

> Attila.

Rémi 

> --
> [0] [ https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html |
> https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html ]

> On Fri, Nov 1, 2024 at 7:28 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> From: "Attila Szegedi" < [ mailto:szegedia at gmail.com | szegedia at gmail.com ] >
>>> To: "Packiaraj S" < [ mailto:s.packiaraj at gmail.com | s.packiaraj at gmail.com ] >
>>> Cc: "nashorn-dev" < [ mailto:nashorn-dev at openjdk.org | nashorn-dev at openjdk.org ]
>>> >
>>> Sent: Friday, November 1, 2024 6:48:14 PM
>>> Subject: Re: High CPU consumption with Java-21 + Nashorn 15.4

>>> Hi Packiaraj,
>>> I suspect a particular issue might be at play here. Specifically, Nashorn used
>>> to be able to rely on Unsafe.defineAnonymousClass to use a more lightweight
>>> method to load compiled code. This was unfortunately taken away with Java 17.
>>> You can test this assumption by running your system on Java 16 and see whether
>>> the performance gets restored. Unfortunately, there's not much we can do to fix
>>> that. Nashorn will use Unsafe.defineAnonymousClass when available, but on Java
>>> 17+ it is no longer.

>> Hello Attila,
>> you can use not use Lookup.defineHiddenClass(bytes, true, NESTMATE) instead ?
>> [ https://bugs.openjdk.org/browse/JDK-8266760 |
>> https://bugs.openjdk.org/browse/JDK-8266760 ]

>>> However, you can, in fact, share ScriptEngine instances across threads, and you
>>> should prepare all your scripts into CompiledScript instances if you can. What
>>> you shouldn't share is Bindings. I wrote about this in some detail in this SO
>>> answer: [ https://stackoverflow.com/a/30159424/131552 |
>>> https://stackoverflow.com/a/30159424/131552 ] , and also less comprehensively
>>> here: [ https://stackoverflow.com/a/34122641/131552 |
>>> https://stackoverflow.com/a/34122641/131552 ]

>>> Hope this helps.
>>> Attila.

>> regards,
>> Rémi

>>> On Fri, Oct 25, 2024 at 5:21 PM Packiaraj S < [ mailto:s.packiaraj at gmail.com |
>>> 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 [
>>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L1454
>>>> | method ] , more specifically during [
>>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L217
>>>> | ContextCodeInstaller.initialize ] and [ http://namedcontextcodeinstaller./ |
>>>> NamedContextCodeInstaller. ] [
>>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L290
>>>> | 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.g etVersionDirName 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/20241102/4695d932/attachment-0001.htm>