Downloaded 88 times
Uploaded byTomer Gabel
Nashorn: JavaScript that doesn’t suck (ILJUG)
Nashorn is a JavaScript engine integrated with Java, aimed at improving performance and compliance compared to the existing Rhino engine. Launched in 2014 with Java 8, it supports ECMAScript 5.1, dynamic linking, and enhanced interoperability with Java through JSR-223 and invokedynamic. Its performance is significantly better than Rhino, achieving speeds 2-10 times faster and around 60% of V8's performance.
More Related Content
Similar to Nashorn: JavaScript that doesn’t suck (ILJUG)
![invokedynamic for Mere Mortals [Code One 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/oco19indyfmm-191015115509-thumbnail.jpg?width=640&height=640&fit=bounds)
Nashorn: JavaScript that doesn’t suck (ILJUG)
- 1. Nashorn: JavaScript that doesn’tsuck Tomer Gabel, Wix ILJUG, April 2014
- 2. Agenda • History • Features •Behind the scenes • Performance • Juggling Act
- 3. History • Existing Rhinoengine: – Slow – Non-compliant – Did I mention slow? • JavaScript since 1998: – Adoption went through the roof – Technology advances (V8, SpiderMonkey…)
- 4. Nashorn in anutshell • Project Nashorn – Started in July 2011 – Integrates with JSR- 223 – Reference use-case for JSR-292 • Released with Java 8 in March 2014
- 5. Why bother? Why youcare • 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
- 6. Features • Self-contained • ImplementsECMAScript 5.1 – 100% compliant! • Runtime-compiled to bytecode (no interpreted mode as with Rhino) • Small: 1.5MB JAR • Fast!
- 7. JSR-223 at aglance import javax.script.*; ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine nashorn = manager.getEngineByName("nashorn"); nashorn.eval( "print("hello world!");");
- 8. Integrating JSR-223 • Injectingstate nashorn.put("name", "Schnitzel McFry"); nashorn.eval( "print("hello " + name + "!");");
- 9. Integrating JSR-223 • InvokingJavaScript from Java nashorn.eval( "function hello(name) { " + " print("hello " + name + "!");" + "} " ); Invocable context = (Invocable) nashorn; context.invokeFunction("hello", "world");
- 10. Nashorn Extensions • Javaobject – Java.type – Java.extend – Java.from – Java.to – Java.super • A bunch more
- 11. Integrating JSR-223 • InvokingJava 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");
- 12. Integrating JSR-223 • Implementinga Java interface nashorn.eval( "var runnable = { " + " "run": function() { print("hello world"); }" + "} " ); Invocable invocable = (Invocable) nashorn; Runnable runnable = invocable.getInterface( nashorn.get("runnable"), Runnable.class);
- 13. Integrating JSR-223 • SingleAbstract 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();
- 14.
- 15. The challenge • JavaScriptis dynamic – Things can change at runtime – Optimization is all about assumptions
- 16. The challenge • JavaScriptis dynamic – Things can change at runtime – Optimization is all about assumptions • For example, what is the type of: var x = 500000;
- 17. The challenge • JavaScriptis dynamic – Things can change at runtime – Optimization is all about assumptions • For example, what is the type of: var x = 500000; x *= 500000; And now?
- 18. The challenge • JavaScriptis dynamic – Things can change at runtime – Optimization is all about assumptions • For example, what is the type of: var x = 500000; x *= 500000; And now? • How would you implement this?
- 19. The challenge • Naïvemultiplication 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
- 20. The challenge • That’sjust 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
- 21. The challenge • Runtimecode manipulation is not the JVM’s strong suite – Can only load entire classes – High overhead – Hard PermGen space limit – Class unloading issues
- 22. 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!
- 23. invokedynamic • The nameis misleading • It’s not about invocation • … but about runtime linkage invokedynamic Bootstrap Method Target Call Site Compile-time Runtime Invokes Returns MethodHandle
- 24. java.lang.invoke • MethodHandle – Animmutable function pointer – Composable: • Guards • Exception handlers • Argument mutation – Typesafe and JIT-optimizable • CallSite – Optionally mutable wrapper – Binds an invokedynamic callsite to a target MethodHandle
- 25. Why is thiscool? • 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
- 26. Don’t forget JEP122 • 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)
- 27. Dynalink • An open-sourcelibrary • Builds on top of invokedynamic: – Metaobject protocol – Linkage model • Enables cross-language interop (JRuby, Jython, Nashorn, plain Java) • Open source (Apache-licensed)
- 28. So how doesit perform?
- 29. Pretty damn good! •2-10 times faster than Rhino • ~60% percent of V8 • Not much research out there
- 30. Avatar.js • Implements theNode 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
- 31.
- 32. 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