Nashorn performance regression from JDK8u5 to JDK8u25?

[Bernard Liang]

Hello,

After running some performance tests on the Cartesian product of ([JDK8u5, JDK8u25] x [simple template, complex templates] x [all-or-nothing, streaming chunks] x [single dust instance per thread, pooled dust instances] x [blank Dust instances, Dust instances with templates preloaded]), we find that JDK8u25 performance is very consistently considerably worse than JDK8u5 (by roughly 10-100%, with the average falling somewhere between there). The relevant code has been executed enough times (on the order of 10,000 times) to reach reasonably warmed-up states. If some of the items on the axes of the Cartesian product don’t make much sense, you can ignore the fuzzy parts of the detailed breakdown for now, with the general understanding that various different environments have been tested and shown to yield the same results.

Some additional high-level context:

Dust is basically a templating language used to render JSON data into HTML with compilable “templates": https://github.com/linkedin/dustjs (we are at the v2.4.2 tag)

“simple template” = ~150 bytes each of one (precompiled) template + context JSON (attached)
“complex templates” = ~350 compiled templates spanning ~245KB in compiled JS + ~75KB of JSON context (proprietary data)

>From https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it sounded like there were some recent updates made to Nashorn performance around the u20 mark, but that seems to have caused a regression rather than an improvement. Is this something that nashorn-dev is aware of? Is there any way we can help diagnose the issue further using publicly safe data? (If you’re looking for a way to reproduce this, the attached basic Dust template + JSON context should be adequate under almost any environment.)

Regards,
Bernard Liang