> From: "Attila Szegedi" <[email protected]> > To: "Remi Forax" <[email protected]> > Cc: "Packiaraj" <[email protected]>, "nashorn-dev" > <[email protected]> > 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:[email protected] | > [email protected] ] > wrote: >>> From: "Attila Szegedi" < [ mailto:[email protected] | [email protected] ] >>> > >>> To: "Packiaraj S" < [ mailto:[email protected] | [email protected] >>> ] > >>> Cc: "nashorn-dev" < [ mailto:[email protected] | >>> [email protected] ] >>> > >>> 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:[email protected] | >>> [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 [ >>>> 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
