The Java Virtual Machine is Over - The Polyglot VM is here - Marcus Lagergren (Oracle)

The JVM is dead! Long live the Polyglot VM! Marcus Lagergren Oracle

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 2

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. "

It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle."


Who am I?

@lagergren


Program Agenda

§  Introduction

§  History of VM languages and runtimes

§  Emerging languages and language design on top of the JVM

§  Invokedynamic

§  The Nashorn project

§  The Da Vinci Machine Project (MLVM)


Introduction


I am here to talk about…

The Java Runtime: The JVM



The Universal Meta-Execution Environment



The JVM as a multi language runtime



The JVM as a multi language runtime

(especially in the context of dynamic languages)


History (what is a runtime

anyway?)


LISP


LISP

1950s – First compiler in 1962


LISP

1950s – First compiler in 1962 Just-in-time compilation


LISP

1950s – First compiler in 1962 Just-in-time compilation GC – Reference Counting


Smalltalk


Smalltalk

First class library


Smalltalk

First class library First visual GUI driven IDE


Smalltalk

First class library First visual GUI driven IDE BYTECODE!


Emerging languages (especially on the

JVM)


Dynamic Languages

ActionScript Adenine APL BASIC BeanShell Clojure ColdFusion Dart Dylan Groovy E Fancy JavaScript

Julia Lua MATLAB Objective-C Perl PHP Powershell Python Qore R

REBOL REXX Ruby Scheme Smalltalk Snit Tcl VBScript Yoix etc

etc etc etc…


Dynamic Languages

•  Dynamic Languages are hot today because •  They are easy to use •  They have no explicit compile stage •  They have good code readability •  Allow short development time for small projects •  Performance is good enough


Trendy Dynamic Languages



Already on top of the JVM


… and of course

V8, Futhark, Carakan, SpiderMonkey, JägerMonkey, *Monkey, Nitro, Rhino, Nashorn, etc etc


Dynamic Languages – Implementation



•  Native Runtimes •  Ruby, Perl, Python, v8, *monkey etc




•  Metacircular •  PyPy, Steel Banks Common LISP, Rubinius (well

partly), Smalltalk





partly), Smalltalk •  On top of a (J)VM

•  Clojure, Jython, JRuby, Rhino, Nashorn •  DLR/CLR


Dynamic Languages – Characteristics

•  Most emerging JVM languages today are dynamic •  As opposed to “non-dynamic” I guess… •  What is a dynamic language? •  Is there a formal definition?



•  Loosely typed •  Dynamic binding

•  Resolve functions/members/calls at runtime rather than compile time



•  Liberal redefinition policy •  Redefine/modify a class •  Redefine/modify a function



•  Liberal redefinition policy •  Redefine/modify a class •  Redefine/modify a function •  Redefine a builtin even •  Oh, go to hell, JavaScript!

Math.sin = function(x){ return 17; }



•  Code equals data •  eval / REPL •  Automatic memory management



•  But you can extend Java at runtime too, can’t you? •  Maybe a “non dynamic” language is more like C? •  I don’t think the “dynamic” prefix matters much

•  Things change at runtime – handle it


Putting your language on top of the JVM


Why?

•  You get so much for free •  Automatic memory management •  State of the art JIT optimizations •  Native threading capability •  Hybridization (JSR-223) •  Man decades of high tech


Why?

0

100000

200000

300000

400000

500000

Code bases

Lines


Why?

0

100000

200000

300000

400000

500000

Code bases

Lines

If it were all about code complexity – TOTALLY WORTH IT!


“All problems in computer science can be solved by another level of indirection”

- David Wheeler



- David Wheeler

•  Sounds good! Implement it! •  Just serve up some bytecode •  People have been doing it since 1996


They have been doing it a lot, actually…

Fantom

Fortress

BeanShell

Jaskell

ANTLR

ABCL

Erjang

X10

jgo

Nice

Gosu

Jacl



- David Wheeler



- David Wheeler

“Except for the problem of too many layers of indirection” - Kevlin Henney


So why is it hard?


So why is it hard?

•  Different levels of “hard” •  Square peg, round hole or round peg, oval hole? •  Scala is a fairly good fit*


So why is it hard?

•  Different levels of “hard” •  Square peg, round hole or round peg, oval hole? •  Scala is a fairly good fit*

•  yes I know about tail call optimization and interface injection – also I was at JVMLS 2013 which left me with mental scars.


So why is it hard?

•  Different levels of “hard” •  Square peg, round hole or round peg, oval hole? •  Scala is a fairly good fit •  Ruby or JavaScript are (at least at first glance) pretty

lousy ones


So why is it hard?

•  Java bytecode [sic] •  Notice the “Java”

•  There are “classes”, “methods”, size limitations, strong types

•  Languages can be much more dynamic than Java •  Different linkage •  Loose types


Not every language has exactly 5 strong types

int, long, float, double, Object int sum(int a, int b) { return a + b; }



int, long, float, double, Object iload_1 iload_2 iadd ireturn



int, long, float, double, Object function sum(a, b) { return a + b; }



int, long, float, double, Object ???? ???? ???? ????


Also: it is hard to swap out code with other code


Applicability and performance

•  The extra layer costs us performance •  How can we work around it?



•  The extra layer costs us performance •  How can we work around it? •  Passive

•  Just wait •  JIT is getting better all the time, GC is getting better

all the time



•  The extra layer costs us performance •  How can we work around it? •  Passive

•  Just wait •  JIT is getting better all the time, GC is getting better

all the time •  Active

•  Punch through the indirection layer •  There are tools these days


Punch through the indirection layer

invokedynamic is my ice pick!


Invokedynamic

•  The first new bytecode since 1996 •  More than new type of call •  Breaks the constraints of Java call/linkage •  Can implement calls that act like function pointers •  More general: can implement custom data access


The whole point: The JVM can optimize this!


invokedynamic bytecode



Bootstrap Method

Calls (once)



Bootstrap Method

java.lang.invoke.CallSite CallSite

Calls (once)

Returns



Bootstrap Method

java.lang.invoke.CallSite CallSite

Target java.lang.invoke.MethodHandle

Calls (once)

Returns

Contains


Example – bootstrap

public static CallSite bootstrap( MethodHandles.Lookup lookup, String name,

MethodType type, Object... metainfo) { //optional

MethodHandle mh = lookup.findStaticMethod( getClass(),

name, type);

return new MyMutableCallsite(mh, metainfo); }


Example – java.lang.invoke •  MutableCallSite (ConstantCallSite)

•  setTarget, getTarget

•  MethodHandles •  guardWithTest

•  filterArguments •  filterReturnValue •  dropArguments

•  etc •  SwitchPoint


Example – dynamic invocation

•  Parameter types known only at run time function add(a, b) {

return a + b; } var res = add(f(), g());




return a + b; } var res = add(f(), g());

int add_int(int a, int b) { return a + b; }




return a + b; } var res = add(f(), g()); int add_int(int a, int b) { return a + b; }

Object add_obj(Object a, Object b){ return JavaScript.ADD(a, b); }



•  Parameter types known only at run time var res = add(f(), g());




boolean intsGuard(Object a, Object b) { return a.getClass() == Integer.class && b.getClass() == Integer.class; }




boolean intsGuard(Object a, Object b) { return a.getClass() == Integer.class && b.getClass() == Integer.class; }

MethodHandle ADD = MethodHandles.guardWithTest( intsGuard, add_int, add_obj);

Object res = ADD(f(), g());


Example – function call reassignment function square(x) { return x * x; } function multiply(x) { return x * 2; } function compute(x) { return square(x) + multiply(x); }


Example – function call reassignment function square(x) { return x * x; } function multiply(x) { return x * 2; } function compute(x) { return square(x) + multiply(x); } multiply = function(x) { return x * 3; }


Example – function call reassignment function square(x) { return x * x; } function multiply(x) { return x * 2; } function compute(x) { return square(x) + multiply(x); } multiply = function(x) { return x * 3; }

UH OH!


Example – lazy constant initialization

•  Call site with one value, available only at runtime •  The “static final” approach won’t work

•  Value calculated once and remains immutable


Example – lazy constant initialization

•  Call site with one value, available only at runtime •  The “static final” approach won’t work

•  Value calculated once and remains immutable

return new ConstantCallSite( MethodHandles.constant(

Data.class, loadDataFromDataBase());


Java 8 also uses invokedynamic

(Delegators with lambda)


The Nashorn Project


What is Nashorn?

•  Nashorn is a 100% pure Java runtime for JavaScript •  Nashorn generates bytecode

•  Invokedynamics are everywhere •  Nashorn currently performs somewhere on the order of

~2-10x better than Rhino •  Nashorn is in JDK 8 •  Nashorn is 100% ECMAScript compliant •  Nashorn has a well thought through security model


Why Nashorn?

•  Started as an invokedynamic POC. •  Rhino is still alive today after ~18 years. Why?

•  JSR-223 •  Nashorn is now mature and replaces Rhino for Java 8


Rationale – JavaScript?

•  Extremely dynamic •  All (well, most) setters, getters, calls, have to be

invokedynamics •  Rhino is slow and old •  JSR-223

•  Should make it easy to provide POC apps for Nashorn


Rationale


Full ECMAScript compliance


Performance

rhino nashorn

0 1 2 3 4 5 6 7 8

rhino

nashorn


Nashorn current performance status

•  As of late August: •  No longer understaffed for performance •  We should try for native-like performance by

•  Modifying the JVM’s invokedynamic implementation

•  Changing Nashorn’s currently conservative type model.


•  Key to native like performance •  In Nashorn: replace conservative types with

optimistic ones – implement rollback mechanism •  In the VM: math intrinsics (done), lambdaform

performance, better inlining, boxing




•  (Very) initial POC after 2.5 weeks of work: •  Broke out octane.crypto.am3 – the hotspot in

the Crypto benchmark in octane. •  Turned it into microbenchmark



•  Runtime

•  Rhino (with –opt 9): 34.6 s •  Nashorn tip: 10.8 s •  V8 1.3 s


Nashorn with optimistic types

•  Runtime



Add JVM math intrinsics…

•  Runtime



Patch JVM to keep more type info while inlining…

•  Runtime



More information

•  We now run larger apps •  My JVMLS 2013 talk “Nashorn War Stories”

•  http://tinyurl.com/nashorn-war-stories-slides

•  http://tinyurl.com/nashorn-war-stories

(unshortened URLs)

http://www.slideshare.net/lagergren/lagergren-jvmls2013final

http://medianetwork.oracle.com/video/player/2630340183001


Nashorn on the Server: Avatar.js

•  Server side JavaScript on the JVM •  An implementation of the node programming model

•  For writing enterprise applications in Java and JavaScript

•  Automatically provides seamless integration with existing Java libraries

•  Parallelism / background Java threads •  Small enough for the embedded space •  http://avatar-js.java.net


Further POC: Askari Debugger

•  Debugger for Nashorn written in Nashorn •  Replace / view code while writing it •  3 weeks of work to get it up and running


Nashorn already in OpenJDK 8

Now: more Nashorn performance enhancements

Now: more JVM performance

enhancements


Contribute! 1.  Ask the community to contribute

functionality, testing, performance [analysis], bug fixes, library optimizations, browser simulation frameworks, kick-ass hybrid Java solutions. JVM optimizations

2.  … 3.  PROFIT!

blogs.oracle.com/nashorn

[email protected]


The Da Vinci Machine Project


Can we do better than the ice pick?


Can we do better than the ice pick?

•  Reshape the hole!


Let’s continue building our “future VM”

•  An open source incubator for JVM futures •  Contains code fragments (patches) •  Migration to OpenJDK requires

•  A standard •  A feature release plan

[email protected]


Da Vinci Machine Patches


It’s not just invokedynamic!

The JVM is evolving to become the multi-language runtime


Thank you!

Q&A? @lagergren

The Java Virtual Machine is Over - The Polyglot VM is here - Marcus Lagergren (Oracle)

Technology

Transcript of The Java Virtual Machine is Over - The Polyglot VM is here - Marcus Lagergren (Oracle)