Nashorn: JavaScript that doesn’t suck (ILJUG)

Nashorn: JavaScript
that doesn’t suck
Tomer Gabel, Wix
ILJUG, April 2014

Agenda
• History
• Features
• Behind the scenes
• Performance
• Juggling Act

History
• Existing Rhino engine:
– Slow
– Non-compliant
– Did I mention slow?
• JavaScript since 1998:
– Adoption went through
the roof
– Technology advances
(V8, SpiderMonkey…)

Nashorn in a nutshell
• Project Nashorn
– Started in July 2011
– Integrates with JSR-
223
– Reference use-case
for JSR-292
• Released with Java 8
in March 2014

Why bother?
Why you care
• Extensibility and scripting
– Macro systems (a la VBA)
– Event hooks
• Server-side JavaScript
– More on this later
• End-user programmability
– Rule engines
– Reporting engines/ETL
– BPL and workflow
• … and more
Why Oracle cares
• Atwood’s law
• Node.js
– A real threat to Java’s
server-side growth
• Reference use-case for
JSR-292
– Drive innovation
– Drive optimization
– Reference implementation

Features
• Self-contained
• Implements ECMAScript 5.1
– 100% compliant!
• Runtime-compiled to bytecode
(no interpreted mode as with Rhino)
• Small: 1.5MB JAR
• Fast!

JSR-223 at a glance
import javax.script.*;
ScriptEngineManager manager =
new ScriptEngineManager();
ScriptEngine nashorn =
manager.getEngineByName("nashorn");
nashorn.eval(
"print("hello world!");");

Integrating JSR-223
• Injecting state
nashorn.put("name", "Schnitzel McFry");
nashorn.eval(
"print("hello " + name + "!");");

Integrating JSR-223
• Invoking JavaScript from Java
nashorn.eval(
"function hello(name) { " +
" print("hello " + name + "!");" +
"} " );
Invocable context = (Invocable) nashorn;
context.invokeFunction("hello", "world");

Nashorn Extensions
• Java object
– Java.type
– Java.extend
– Java.from
– Java.to
– Java.super
• A bunch more

Integrating JSR-223
• Invoking Java from JavaScript
nashorn.eval(
"var HashMap = Java.type("java.util.HashMap");" +
"var map = new HashMap(); " +
"map.put("name", "Schnitzel"); " +
"map.put("surname", "McFry"); " );
HashMap<String, String> map =
(HashMap<String, String>) nashorn.get("map");

Integrating JSR-223
• Implementing a Java interface
nashorn.eval(
"var runnable = { " +
" "run": function() { print("hello world"); }" +
"} " );
Invocable invocable = (Invocable) nashorn;
Runnable runnable = invocable.getInterface(
nashorn.get("runnable"), Runnable.class);

Integrating JSR-223
• Single Abstract Method (SAM)
promotion:
nashorn.eval(
"var Thread = Java.type("java.lang.Thread");" +
"var thread = new Thread(function() { " +
" print("hello world"); " +
"} ); " );
Thread thread = (Thread) nashorn.get("thread");
thread.start();
thread.join();

The challenge
• JavaScript is dynamic
– Things can change at runtime
– Optimization is all about assumptions

The challenge
• For example, what is the type of:
var x = 500000;

The challenge
var x = 500000;
x *= 500000; And now?

The challenge
var x = 500000;
x *= 500000; And now?
• How would you implement this?

The challenge
• Naïve multiplication operator:
– Receive LHS and RHS as Objects
– Unbox
– Test for potential over/underflow
– Add via appropriate codepath
– Box and return
• You can specialize via static analysis
• … but on-the-fly optimization is better

The challenge
• That’s just one
example.
– Dynamic dispatch
– Type coercions
– Primitive widening
– Prototype mutation
• All of these per call
site!
function square(x) {
return x * x;
}
square(10) //== 100
square(3.14) //== 9.8596
square("wat") //== NaN

The challenge
• Runtime code manipulation is not the
JVM’s strong suite
– Can only load entire classes
– High overhead
– Hard PermGen space limit
– Class unloading issues

Enter JSR 292
• Based on an experimental project,
the Da Vinci Machine
• Adds two new concepts to the JVM:
– invokedynamic bytecode instruction
– MethodHandles
• The first bytecode extension since
1999!

invokedynamic
• The name is
misleading
• It’s not about
invocation
• … but about
runtime linkage
invokedynamic
Bootstrap
Method
Target
Call Site
Compile-time
Runtime
Invokes
Returns MethodHandle

java.lang.invoke
• MethodHandle
– An immutable
function pointer
– Composable:
• Guards
• Exception handlers
• Argument mutation
– Typesafe and
JIT-optimizable
• CallSite
– Optionally mutable
wrapper
– Binds an
invokedynamic
callsite to a target
MethodHandle

Why is this cool?
• Generated code is linked at runtime
• Code is hotswappable
– Guards for branching (over/underflow)
– SwitchPoints for hotswap (promotions)
• Hotswapping is lightweight
– No class generation or loading
• Resulting codepath can be JITted

Don’t forget JEP 122
• The PermGen space is no more
– Now called “Metaspace”
– Resides in native heap
– Block allocator and classloader isolation
– Dynamic size (with bounds)
• Maximum size (hard)
• Low/high watermark for GC
• This applies to all GCs (not just G1)

Dynalink
• An open-source library
• Builds on top of invokedynamic:
– Metaobject protocol
– Linkage model
• Enables cross-language interop
(JRuby, Jython, Nashorn, plain Java)
• Open source (Apache-licensed)

Pretty damn good!
• 2-10 times faster than Rhino
• ~60% percent of V8
• Not much research out there

Avatar.js
• Implements the Node
model and API on the
JVM
• Supports most
modules
– Some natively
– Some via JNI
• … and it does work!
Supported module highlights
• mocha
• coffee-script
• uglify-js
• underscore
• request
• async
• jade
• express
• mongodb
• Redis
Most popular per nodejsmodules.org

Thank you!
Additional reading:
• Nashorn war stories (from a
battle scarred veteran of
invokedynamic)
• Dynalink
Contact me:
• http://www.tomergabel.com
• tomer@tomergabel.com
• @tomerg

Nashorn: JavaScript that doesn’t suck (ILJUG)

Recommended

More Related Content

What's hot (20)

Similar to Nashorn: JavaScript that doesn’t suck (ILJUG) (20)

More from Tomer Gabel (20)

Recently uploaded (20)

Nashorn: JavaScript that doesn’t suck (ILJUG)