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'. Attila. -- [0] https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html On Fri, Nov 1, 2024 at 7:28 PM Remi Forax <[email protected]> wrote: > > > ------------------------------ > > *From: *"Attila Szegedi" <[email protected]> > *To: *"Packiaraj S" <[email protected]> > *Cc: *"nashorn-dev" <[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 > > > 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, > and also less comprehensively here: > https://stackoverflow.com/a/34122641/131552 > > Hope this helps. > Attila. > > > regards, > Rémi > > > > On Fri, Oct 25, 2024 at 5: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 >> <https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L1454>, >> more specifically during ContextCodeInstaller.initialize >> <https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L217> >> and NamedContextCodeInstaller.install >> <https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L290> >> >> 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 >> > >
