Optimization by invokedynamic

[tuchida]

In a dynamic language running on a JVM, invokedynamic is said to be faster.
In #884, it looks like it was implemented halfway through, but it was closed.

Would you like to discuss your current progress and problems?

[p-bakker]

@gbrail can probably provide a way more elaborate answer, but my take on this is that a lot of work was done in the past by various people to start using invokeDynamic with Rhino.

Some of the people involved then moved onto the Nashorn team to do the same thing, but without the burden of the legacy code of Rhino, basically starting with a clean slate.

In parallel (I think) Oracle worked on what now has become Graal, which also uses invokeDynamic at its core and has replaced Nashorn.

I also think @gbrail has been chipping away at getting the Rhino codebase ready to start thinking about invokeDynamic: I think his slotmap refactoring that went into 1.7.14 is part of it and maybe the lambda thing is related as well: at least I've seen old branches that did invokeDynamic stuff that also contained similar slotmap changes.

Here are a bunch of links to discussions, commits/branches all related to invokeDynamic:

• https://groups.google.com/g/js-jvm/c/FY1zPkMq4zU
• https://github.com/mozilla/rhino/compare/invokedynamic
• https://github.com/mozilla/rhino/commits/greg-dynalink
• d0fcb7f
• https://github.com/mozilla/rhino/commits/greg-indy-math
• https://github.com/mozilla/rhino/commits/greg-indy-properties

As for the current state of things and the challenges to be solved: no idea, hope @gbrail can shed some light there

Some other links related to performance improvements of which I think they never made it into master:

• https://groups.google.com/g/mozilla.dev.tech.js-engine.rhino/c/eABiaSOg4z4/m/pwy0nZL8ypoJ
• https://github.com/hns/rhino-opt/wiki
• https://github.com/mozilla/rhino/commits/new-classy

[tuchida]

(I don't know much about it,) It seems that older Android does not have invokedynamic.
https://developer.android.com/reference/kotlin/java/lang/invoke/package-summary

We need to be careful if the interpreter mode works on Android.

[gbrail]

I've played with this a number of times over the years. The overall idea is that, in theory, a JS engine implemented with liberal use of invokeDynamic can be faster because it can, over time, bind the most efficient way to invoke each task in a cache and skip a lot of evaluation.

Nashorn uses this a lot -- it tries to detect common JS code patterns that "look like objects." Then it creates a brand-new Java class for each type of "object." Then every call site that has to reference a property on the object can be optimized at runtime to simply look up a property on that class, which is probably 1000x more efficient than what we do, which is to search a hash table (and sometimes iterate up a tree of other hashtables). Nashorn can also fall back to what Rhino does when that doesn't work.

Making Rhino do all that would probably be a huge job. This is, I presume, why the Nashorn team decided to start totally from scratch rather than try to adapt Rhino. (However, there is a very old branch in this repo called "classy" that attempts this!)

GraalVM, as I understand it, is a totally different VM and I don't know that there's anything comparable -- IMO people who are already running on Graal should just use it for JS.

However, one place where I thought that invokeDynamic would work is in some of the various complex common functions. For example, "ScriptRuntime.add" is a giant tree of instanceof and other checks, because it has to account for every weird behavior of JavaScript that might happen when you use "+" to connect two variables.

With invokedynamic support, the first time we get to a spot in the code that uses that "+", we might see that the two variables are actually strings, and replace the call to ScriptRuntime.add with a (presumably more efficient) call that just skips all the instanceof checking and goes right to, say, string concatenation.

invokedynamic-based runtimes like Nashorn do this all the time -- each call site is ideally a quick test to ensure that the precondition has not changed, then a dispatch directly to the most efficient way to handle that callsite.

The "jdk.dynalink" package, part of Java 9, is one set of code that might make it a bit easier to do this.

[tonygermano]

The "jdk.dynalink" package, part of Java 9, is one set of code that might make it a bit easier to do this.

When I was reading about this, I gathered that it wasn't really feasible until we have moved past java 8 because of the lack of support in the JDK.

[p-bakker]

Which brings us to the question of moving away from Java 8 to some newer version. Java 9? Java 11?

See #1169 and #1075.

Personally I feel we should make such move in a v2.0.0 release, but thats just me. Would love to get the discussion on this going though

[p-bakker]

Just came across https://www.infoq.com/news/2011/10/dynjs/, another EcmaScript engine impl. on the JVM. Seems abandoned, but was another attempt to write a JS Engine based on invokeDynamic.

Just referencing it here as an FYI