The jvm is dead long live the polyglot vm
Sponsored Links
This presentation is the property of its rightful owner.
1 / 123

The JVM is dead! Long live the Polyglot VM! PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on
  • Presentation posted in: General

The JVM is dead! Long live the Polyglot VM!. Marcus Lagergren Oracle. 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.

Download Presentation

The JVM is dead! Long live the Polyglot VM!

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The JVM is dead!Long live the Polyglot VM!

Marcus Lagergren

Oracle


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


I am here to talk about…

The Universal Meta-Execution Environment


I am here to talk about…

The Universal Meta-Execution Environment


I am here to talk about…

The JVM as a multi language runtime


I am here to talk about…

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

FIRST JIT EVER!

1950s – First compiler in 1962

Just-in-time compilation


LISP

1950s – First compiler in 1962

Just-in-time compilation

GC – Reference Counting


LISP

FIRST MODERN

ADAPTIVE RUNTIME!

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!


Smalltalk

NOTHING NEW UNDER

THE SUN SINCE?

First class library

First visual GUI driven IDE

BYTECODE!


Emerging languages (especially on the JVM)


Dynamic Languages

ActionScript Adenine APL BASIC BeanShellClojure 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 Yoixetcetcetc etc…


Dynamic Languages

ActionScript Adenine APL BASIC BeanShellClojureColdFusion Dart Dylan Groovy E Fancy JavaScript Julia Lua MATLAB Objective-C Perl PHPPowershellPythonQore R REBOL REXX Ruby Scheme Smalltalk Snit Tcl VBScript Yoixetcetcetc 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


Trendy Dynamic Languages


Trendy Dynamic Languages


Trendy Dynamic Languages


Trendy Dynamic Languages

Already on top of the JVM


Trendy Dynamic Languages

Already on top of the JVM


… and of course

V8, Futhark, Carakan, SpiderMonkey,

JägerMonkey, *Monkey, Nitro, Rhino,

Nashorn, etcetc


Dynamic Languages – Implementation


Dynamic Languages – Implementation

  • Native Runtimes

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


Dynamic Languages – Implementation

  • Native Runtimes

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

  • Metacircular

    • PyPy, Steel Banks Common LISP, Rubinius (well partly), Smalltalk


Dynamic Languages – Implementation

  • Native Runtimes

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

  • Metacircular

    • PyPy, Steel Banks Common LISP, Rubinius (well partly), Smalltalk

  • On top of a (J)VM

    • Clojure, Jython, JRuby, Rhino, Nashorn

    • DLR/CLR


Dynamic Languages – Implementation

  • Native Runtimes

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

  • Metacircular

    • PyPy, Steel Banks Common LISP, Rubinius (well 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?


Dynamic Languages – Characteristics

  • Loosely typed

  • Dynamic binding

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


Dynamic Languages – Characteristics

  • Liberal redefinition policy

    • Redefine/modify a class

    • Redefine/modify a function


Dynamic Languages – Characteristics

  • 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;

}


Dynamic Languages – Characteristics

  • Code equals data

  • eval/ REPL

  • Automatic memory management


Dynamic Languages – Characteristics

  • 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?


Why?

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


“All problems in computer science can be solved by

another level of indirection”

- 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…

jgo

ANTLR

Jaskell

Gosu

Fortress

Nice

ABCL

X10

Erjang

BeanShell

Jacl

Fantom


“All problems in computer science can be solved by

another level of indirection”

- David Wheeler


“All problems in computer science can be solved by

another level of indirection”

- David Wheeler

“Except for the problem of too many layers of indirection”

- KevlinHenney


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”

    • 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;

}


Not every language has exactly 5 strong types

int, long,float, double, Object

iload_1

iload_2

iadd

ireturn


Not every language has exactly 5 strong types

int, long,float, double, Object

function sum(a, b) {

return a + b;

}


Not every language has exactly 5 strong types

int, long,float, double, Object

????

????

????

????


Not every language has exactly 5 strong types

int, long,float, double, Object

THIS IS

A BIG PROBLEM!

????

????

????

????


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


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

THIS IS

A BIG PROBLEM!


Applicability and performance

  • The extra layer costs us performance

  • How can we work around it?


Applicability and performance

  • 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


Applicability and performance

  • 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!


invokedynamicbytecode


invokedynamicbytecode

Calls (once)

Bootstrap Method


invokedynamicbytecode

Calls (once)

Bootstrap Method

Returns

CallSite

java.lang.invoke.CallSite


invokedynamicbytecode

Calls (once)

Bootstrap Method

Returns

CallSite

java.lang.invoke.CallSite

Contains

Target

java.lang.invoke.MethodHandle


Example – bootstrap

public static CallSitebootstrap(

MethodHandles.Lookuplookup,

String name,

MethodType type,

Object... metainfo) { //optional

MethodHandlemh = 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(g(), g());


Example – dynamic invocation

  • Parameter types known only at run time

function add(a, b) {

return a + b;

}

var res = add(g(), g());

intadd_int(int a, int b) {

return a + b;

}


Example – dynamic invocation

  • Parameter types known only at run time

function add(a, b) {

return a + b;

}

var res = add(g(), g());

intadd_int(int a, int b) {

return a + b;

}

Object add_obj(Object a, Object b){

return JavaScript.ADD(a,b);

}


Example – dynamic invocation

  • Parameter types known only at run time

var res = add(g(), g());


Example – dynamic invocation

  • Parameter types known only at run time

var res = add(g(), g());

booleanintsGuard(Object a, Object b) {

return a.getClass() == Integer.class &&

b.getClass() == Integer.class;

}


Example – dynamic invocation

  • Parameter types known only at run time

var res = add(g(), g());

booleanintsGuard(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(g(), 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;

}


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


Performance

THIS IS JUST

THE BEGINNING


Nashorn current performance status

  • As of 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.


Nashorn current performance status

  • 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


Nashorn current performance status

  • (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


Nashorn current performance status

  • Runtime

    • Rhino (with –opt 9): 34.6 s

    • Nashorn tip: 10.8s

    • V8 1.3 s


Nashorn with optimistic types

  • Runtime

    • Rhino (with –opt 9): 34.6 s

    • Nashorn tip: 5.8 s

    • V8 1.3 s


Add JVM math intrinsics…

  • Runtime

    • Rhino (with –opt 9): 34.6 s

    • Nashorn tip: 4.4 s

    • V8 1.3 s


Patch JVM to keep more type info while inlining…

  • Runtime

    • Rhino (with –opt 9): 34.6 s

    • Nashorn tip: 2.5 s

    • V8 1.3 s


More information

  • 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 8Now: more Nashorn performance enhancementsNow: more JVM performance enhancements


Contribute!

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

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


  • Login