<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Attila Szegedi" <szegedia@gmail.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Packiaraj" <s.packiaraj@gmail.com>, "nashorn-dev" <nashorn-dev@openjdk.org><br><b>Sent: </b>Friday, November 1, 2024 9:37:56 PM<br><b>Subject: </b>Re: High CPU consumption with Java-21 + Nashorn 15.4<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">Hi Remi,<br><div>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. </div><br><div>Regardless, using a single ScriptEngine mostly remedies the issue. I would still love to get a VISIBLE ClassOption for the hidden classes tho'.</div></div></blockquote><div><br data-mce-bogus="1"></div><div>Let's prentend my memory is ok, 2020 was a special year :)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I think we should try to ask for the VISISBLE classOption again.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><div>Attila.</div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><div>--</div><div>[0] <a href="https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html" target="_blank">https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html</a><br data-mce-bogus="1"></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 1, 2024 at 7:28 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br><br><hr id="m_8153185395533890882zwchr"><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Attila Szegedi" <<a href="mailto:szegedia@gmail.com" target="_blank">szegedia@gmail.com</a>><br><b>To: </b>"Packiaraj S" <<a href="mailto:s.packiaraj@gmail.com" target="_blank">s.packiaraj@gmail.com</a>><br><b>Cc: </b>"nashorn-dev" <<a href="mailto:nashorn-dev@openjdk.org" target="_blank">nashorn-dev@openjdk.org</a>><br><b>Sent: </b>Friday, November 1, 2024 6:48:14 PM<br><b>Subject: </b>Re: High CPU consumption with Java-21 + Nashorn 15.4<br></blockquote></div><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">Hi Packiaraj,<br><div>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.</div></div></blockquote><br><div>Hello Attila,<br></div><div>you can use not use Lookup.defineHiddenClass(bytes, true, NESTMATE) instead ?<br></div><div> <a href="https://bugs.openjdk.org/browse/JDK-8266760" target="_blank">https://bugs.openjdk.org/browse/JDK-8266760</a><br></div><br><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><br><div>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: <a href="https://stackoverflow.com/a/30159424/131552" target="_blank">https://stackoverflow.com/a/30159424/131552</a>, and also less comprehensively here: <a href="https://stackoverflow.com/a/34122641/131552" target="_blank">https://stackoverflow.com/a/34122641/131552</a><br></div><br><div>Hope this helps.</div><div> Attila.</div></div></blockquote><br><div>regards,<br></div><div>Rémi<br></div><br><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2024 at 5:21 PM Packiaraj S <<a href="mailto:s.packiaraj@gmail.com" target="_blank">s.packiaraj@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_8153185395533890882m_-4918169543054684356gmail-:sz" style="direction:ltr;min-height:626px"><font face="georgia, serif">Hello, <br><br><font color="#000000"><span style="font-size:14px;font-variant-ligatures:no-common-ligatures">We use Nashorn with Tomcat as a long running service. </span></font>We recently migrated to Java 21. ( from java 11 and the performance is good with Java-11).<br>Since Nashorn is moved out of JDK we have pulled in '<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><b>nashorn-core-15.4.jar</b>' and its dependency (<b>asm</b>*) and loaded it as a regular jar. Functionality everything looks ok. <br><br>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. <br><br>Upon investigation using profiler (jvisualVM) looks like most of the CPU is spent in compile <a href="https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L1454" target="_blank">method</a>, more specifically during <a href="https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L217" target="_blank">ContextCodeInstaller.initialize</a> and </span><a href="http://NamedContextCodeInstaller." target="_blank">NamedContextCodeInstaller.</a></font><span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><font face="georgia, serif"><a href="https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L290" target="_blank">install</a><br><br>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.<br><br>so, how to improve the performance of the Nashorn engine, specifically the `compile` part.<br>Is there any other option we can try? BTW, </font></span><span style="font-family:georgia,serif;color:rgb(0,0,0);font-size:14px;font-variant-ligatures:no-common-ligatures">persistent-code-cache did not help as </span><span style="font-family:georgia,serif;font-size:9.8pt;color:rgb(8,8,8)">OptimisticTypesPersistence.g</span><span style="font-family:georgia,serif;color:rgb(8,8,8);font-size:9.8pt">etVersionDirName is performing poorly </span><div><span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><font face="georgia, serif"><br>Test code that we used to study this high CPU issue is attached. </font></span></div><div><span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><font face="georgia, serif"><br></font></span></div><div><span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><font face="georgia, serif">Thanks a lot for hemp & any insight </font><br></span></div><div><span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-size:14px"><font face="georgia, serif">Sakkanan</font></span></div></div></div>
</blockquote></div></blockquote></div></div></div></blockquote></div><br></blockquote></div></div></body></html>