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

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."

2

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

Who am I?

@lagergren
3


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)

4


Introduction
5


I am here to talk about…

The Java Runtime:
The JVM
6



The Universal MetaExecution Environment
7



The Universal MetaExecution Environment
8



The JVM as a multi
language runtime
9



The JVM as a multi
language runtime
(especially in the context of dynamic languages)
10


History
(what is a runtime
anyway?)
11


LISP

12


LISP

1950s – First compiler in 1962

13


LISP

Just-in-time compilation
14


LISP

15


LISP

GC – Reference Counting
16


LISP

GC – Reference Counting
17


Smalltalk

18


Smalltalk

First class library

19


Smalltalk

First class library
First visual GUI driven IDE
20


Smalltalk

First class library
BYTECODE!
21


Smalltalk

First class library
BYTECODE!
22


Emerging languages
(especially on the
JVM)
23


Dynamic Languages

24

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

25

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
• 

26

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

27



28



29



30



Already on top of the JVM

31



Already on top of the JVM

32


… and of course

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

33


34


35


36


37


Dynamic Languages – Implementation

38


• 

39

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


• 

• 

40

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


• 

• 

• 

41

Native Runtimes
• 
Metacircular
• 
partly), Smalltalk
On top of a (J)VM
• 
Clojure, Jython, JRuby, Rhino, Nashorn
• 
DLR/CLR

• 

• 

• 

42

Native Runtimes
• 
Metacircular
• 
partly), Smalltalk
On top of a (J)VM
• 
Clojure, Jython, JRuby, Rhino, Nashorn
• 
DLR/CLR

Dynamic Languages – Characteristics
• 
• 
• 
• 

43

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


• 
• 

44

Loosely typed
Dynamic binding
• 
Resolve functions/members/calls at runtime rather
than compile time


• 

45

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


• 

46

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

• 
• 
• 

47

Code equals data
eval / REPL
Automatic memory management


• 
• 
• 

48

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

49


Why?
• 

50

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?

Code bases
500000
400000
300000
200000
100000
0

51


Lines

Why?

Code bases
500000
400000
300000
200000
100000
0

Lines

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

52


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

53


- David Wheeler
• 
• 
• 

54

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

55


Fantom

- David Wheeler

56


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

57


So why is it hard?

58


So why is it hard?
• 
• 
• 

59

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


So why is it hard?
• 
• 
• 

• 

60

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

61

Scala is a fairly good fit
Ruby or JavaScript are (at least at first glance) pretty
lousy ones


So why is it hard?
• 

• 

• 

62

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

63


iload_1
iload_2
iadd
ireturn

64


function sum(a, b) {
return a + b;
}

65


????
????
????
????

66


????
????
????
????

67


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

68


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

69


Applicability and performance
• 
• 

70

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


• 
• 
• 

71

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


• 
• 
• 

• 

72

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!

73


Invokedynamic
• 
• 
• 
• 
• 

74

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


invokedynamic
bytecode

76


invokedynamic
bytecode

Calls (once)

Bootstrap Method

77


invokedynamic
bytecode

Calls (once)

Bootstrap Method
Returns
CallSite

java.lang.invoke.CallSite

78


invokedynamic
bytecode

Calls (once)

Bootstrap Method
Returns
CallSite

java.lang.invoke.CallSite
Contains
Target

java.lang.invoke.MethodHandle

79


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);
}

80


Example – java.lang.invoke
• 

• 

• 
81

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());

82


• 

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

83


• 

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

84


• 


85


• 

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

86


• 

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());

87


Example – function call reassignment
function
return
}
function
return
}
function
return
}

88


square(x) {
x * x;
multiply(x) {
x * 2;
compute(x) {
square(x) + multiply(x);

function
return
}
function
return
}
function
return
}
multiply
return
}

89


square(x) {
x * x;
multiply(x) {
x * 2;
compute(x) {
= function(x) {
x * 3;


UH OH!

90

function
return
}
function
return
}
function
return
}
multiply
return
}


square(x) {
x * x;
multiply(x) {
x * 2;
compute(x) {
= function(x) {
x * 3;

Example – lazy constant initialization

• 

• 

91

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());

92


Java 8 also uses
invokedynamic
(Delegators with lambda)

93


The Nashorn Project

94


What is Nashorn?
• 
• 

• 

• 
• 
• 

95

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

• 

96

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


97


98


Rationale – JavaScript?

• 

• 
• 

99

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

100


Full ECMAScript compliance

101


Performance
8
7
6
5
4
3
2
1
0

rhino
nashorn
nashorn
rhino

102


Performance
8
7
6
5
4
3
2
1
0

rhino
nashorn
nashorn
rhino

103


Nashorn current performance status
• 

104

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.


• 

105

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


• 

106

(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


• 

107

Runtime
• 
Rhino (with –opt 9):
• 
Nashorn tip:
• 
V8


34.6 s
10.8 s
1.3 s

Nashorn with optimistic types
• 

108

Runtime
• 
• 
Nashorn tip:
• 
V8


34.6 s
5.8 s
1.3 s

Add JVM math intrinsics…
• 

109

Runtime
• 
• 
Nashorn tip:
• 
V8


34.6 s
4.4 s
1.3 s

Patch JVM to keep more type info while
inlining…
• 

110

Runtime
• 
• 
Nashorn tip:
• 
V8


34.6 s
2.5 s
1.3 s

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
111


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

• 
• 

• 

• 

112


Further POC: Askari Debugger

• 
• 
• 

113

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
114


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
nashorn-dev@openjdk.java.net
115


The Da Vinci Machine
Project

116


Can we do better than the ice pick?

117


Can we do better than the ice pick?

• 

118

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
mlvm-dev@openjdk.java.net

119


Da Vinci Machine Patches

120


It’s not just invokedynamic!

The JVM is evolving to become the
multi-language runtime
121


Thank you!

Q&A?
@lagergren

122


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie The Java Virtual Machine is Over - The Polyglot VM is here - Marcus Lagergren (Oracle) (20)

Mehr von jaxLondonConference

Mehr von jaxLondonConference (18)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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