JVM: A Platform for Multiple Languages

Insert Picture HereJVM: A Platform for Multiple LanguagesKrystal MoMember of Technical StaffHotSpot JVM Compiler Team

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.

Once there was a time…

Source: http://www.tiobe.com

Oh wait…

JavaTM

But really, what we meant was…

JavaTM

Fortunately, clearer minds prevailLanguage Implementations on JVM

Fantom

Fortress

(and many more…)

BeanShell

Jaskell

JudoScript

Erjang

myForth

jdartjgo

Agenda

Why make a language on JVM

Language features by emulation

What we did in JDK 7

Building the future

Agenda

Building the future

Why Make a Language At All? (1)

Syntax– the “easy” part

– pick one that fits your eyes

Semantics and Capabiliies– static vs. dynamic

– sequential vs. parallel

– …one that fits the problem domain

Why Make a Language At All? (2)

Language can use alternative syntax– where as library has to adhere to some host language

Language can impose more restrictions– e.g. controlling capability

– where as library has no control over host language’s capabilities

Versus writing a library

Why on JVM?

Mature low-level services– Dynamic (“JIT”) compilation

– Garbage collection

– Threading

– Debugging Support

Cross-platform Vast array of libraries

JVM StrengthsCompiler Optimizations

compiler tactics delayed compilation tiered compilation on-stack replacement delayed reoptimization program dependence graph representation static single assignment representationproof-based techniques exact type inference memory value inference memory value tracking constant folding reassociation operator strength reduction null check elimination type test strength reduction type test elimination algebraic simplification common subexpression elimination integer range typingflow-sensitive rewrites conditional constant propagation dominating test detection flow-carried type narrowing dead code elimination

language-specific techniques class hierarchy analysis

devirtualization symbolic constant propagation autobox elimination escape analysis lock elision lock fusion de-reflectionspeculative (profile-based) techniques optimistic nullness assertions optimistic type assertions optimistic type strengthening optimistic array length strengthening untaken branch pruning optimistic N-morphic inlining branch frequency prediction call frequency predictionmemory and placement transformation expression hoisting expression sinking redundant store elimination adjacent store fusion card-mark elimination merge-point splitting

loop transformations loop unrolling loop peeling safepoint elimination

iteration range splitting range check elimination loop vectorizationglobal code shaping inlining (graph integration) global code motion heat-based code layout switch balancing throw inliningcontrol flow graph transformation local code scheduling local code bundling delay slot filling graph-coloring register allocation linear scan register allocation live range splitting copy coalescing constant splitting copy removal address mode matching instruction peepholing DFA-based code generator

Why in Java?

Robustness: Runtime exceptions not fatal Reflection: Annotations instead of macros Tooling: Java IDEs speed up the development process etc.

Instead of C/C++?

Good IDEs Good Profilers Good tooling for developing

parsers and other language support

Excellent Tooling Support

Ease of Development

Developing a Language on JVM

Backed by JVM

SemanticsSyntax Low-level Details

•(your work goes here)•Backed by various libraries•e.g. ASM, dynalink

•Mature parser libraries•e.g. ANTLR, JavaCC

Case Study: Writing a Compiler in JavaUsing Reflection

for (IfNode n : graph.getNodes(IfNode.class)) { ... }

class CompareNode extends FloatingNode, implements ValueNumberable, Canonicalizable { @Input ValueNode x; @Input ValueNode y; @Data Condition condition;

public Node canonical(CanonicalizerTool t) { return this; }}

Agenda

Building the future

It can always be done

Java and JVM provide a rich set of primitives to build on Almost any language feature can be implemented on JVM

– albeit not necessarily efficient

Even without direct native support from JVM

David Wheeler

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

Kevlin Henney

“… except for the problem of too many layers of indirection.”

Case Study: A Bytecode Interpreter in Java“Double interpretation”

Java Source Program

Bytecode Interpreter in Java

Host JVM(also an interpreter)

Bytecode

i = j + 1

iload_2iconst_1iaddistore_1

while (true) { byte opcode = code[pc++]; switch (opcode) { // ... case ILOAD_2: int i = locals[2]; stack[sp++] = i; break; // ... }}

……………………………

Case Study: A JVM in JavaIdeally, redundant indirections are squeezed out

Java Source Program

Compiler in Java

Host MachineBytecode

i = j + 1

iload_2iconst_1iaddistore_1

lea eax, [edx+1]

Alternative Method Dispatching

e.g. prototype-based dispatch, metaclass, etc. Emulate with reflection

– Custom lookup / binding

– Then java.lang.reflect.Method.invoke()

– Reflective invocation overhead Security checking Argument boxing / unboxing

Tail-calls

Often seen in functional languages Emulate with trampoline loop Special case:

– Direct tail-recursions can easily be transformed into loops

– e.g. Scala does this

Case Study: tail-callRewrite into trampoline

static int a() { return b();}

static int b() { return c();}

static int c() { return 42;}

static int trampolineLoop(Task t) { Context ctx = new Context(); while (t != null) { t = t.invoke(ctx); } return ctx.value;}

static Task a(Context ctx) { return new Task(#b);}

static Task b(Context ctx) { return new Task(#c);}

static Task c(Context ctx) { ctx.value = 42; return null;}

Case Study: tail-recursionRewrite into loop

static int fib(int n) { return fibInner(n, 0, 1);}

static int fibInner(int n, int a, int b) { if (n < 2) return b; return fibInner(n - 1, b, a + b);}

static int fib(int n) { int a = 0, b = 1; while (n >= 2) { n = n - 1; int temp = a + b; a = b; b = temp; } return b;}

Coroutines

Emulate with threads– Can implement full (“stackful”) coroutine semantics

– Often use thread pooling as an optimization

– Waste (virtual) memory

– Could leak memory

– e.g. used by JRuby on stock JVMs

Coroutines

Emulate with Finite State Machines– Compile-time transformation

– Can only implement “stackless coroutines” Can only yield from the main method

– e.g. C# does this with its iterator

– e.g. there’s a coroutines library for Java that does the same

Case Study: C#’s iteratorOriginal source

static IEnumerable<int> GetNaturals() { int i = 1; while (true) { yield return i++; }}

Case Study: C#’s iteratorTransformed into FSM (simplied from actual generated code)

static IEnumerable<int> GetNaturals() { return new NaturalsIterator(0);}

sealed class NaturalsIterator : IEnumerable<int>, IEnumerable, IEnumerator<int>, IEnumerator, IDisposable { int _current, _state, _i; public NaturalsIterator(int state) { _state = state; } int IEnumerator<int>.Current { get { return _current; }

} bool IEnumerator.MoveNext() { switch (_state) { case 0: _i = 1; break; case 1: break; default: return false; } _current = _i++; _state = 1; return true; }}

Reference Counting

Emulate with reified reference– Boxing overhead

– You really don’t want to do this…

public class CountedReference<T> { private volatile int refCount = 1; private final T target; public CountedReference(T target) { this.target = target; } public T addRef() { refCount++; return target; } public void release() { if (refCount >= 1) refCount--; if (refCount < 1 && target != null) { target.finalize(); target = null; } }}

Infinite Precision Integer

Emulate with java.math.BigInteger– Boxing overhead

Performance impact Heap bloat

Closer to the Metal

Less indirections Better performance

Reducing redundant emulation

The “J” in JVM

Semantics match => good perf, easy to impl Closer to Java => closer to the metal on JVM

Geared towards Java semantics

The “J” in JVM

Languages on JVM shouldn’t be forced to be like Java to be performant

Improve the VM to accommodate non-Java language features– In turn, benefits Java itself, e.g. lambdas

Should optimize for non-Java features, too

Agenda

Building the future

Why dynamic languages?

Fast turnaround time for simple programs– no compile step required

– direct interpretation possible

– loose binding to the environment

Data-driven programming– program shape can change along with data shape

– radically open-ended code (plugins, aspects, closures)

Dynamic languages are here to stay

What slows down a JVM

Non-Java languages require special call sites.– e.g.: Smalltalk message sending (no static types).

– e.g.: JavaScript or Ruby method call (different lookup rules).

In the past, special calls required simulation overheads– ...such as reflection and/or extra levels of lookup and indirection

– ...which have inhibited JIT optimizations.

Result: Pain for non-Java developers. Enter Java 7.

Key Features

New bytecode instruction: invokedynamic.– Linked reflectively, under user control.

– User-visible object: java.lang.invoke.CallSite

– Dynamic call sites can be linked and relinked, dynamically.

New unit of behavior: method handle– The content of a dynamic call site is a method handle.

– Method handles are function pointers for the JVM.

– (Or if you like, each MH implements a single-method interface.)

Dynamic Program Composition

Method Handles

BytecodesDynamic Call

JVM JIT

A dynamic call site is created for each invokedynamic call bytecode

Each call site is bound to one or more method handles, which point back to bytecoded methods

Bytecodes are created by Java compilers or dynamic runtimes

The JVM seamlessly integrates execution, optimizing to native code as necessary

Passing the burden to the JVM

Non-Java languages require special call sites. In the past, special calls required simulation overheads

Now, invokedynamic call sites are fully user-configurable– ...and are fully optimizable by the JIT.

Result: Much simpler code for language implementors– ...and new leverage for the JIT.

What’s in a method call? (before invokedynamic)

Source code Bytecode Linking Executing

Naming Identifiers Utf8 constants JVM “dictionary”

Selecting Scopes Class names Loaded classes

V-table lookup

Adapting Argument conversion

C2I / I2C adapters

Receiver narrowing

Calling Jump with arguments

What’s in a method call? (using invokedynamic)

Source code Bytecode Linking Executing

Naming ∞ ∞ ∞ ∞

Selecting ∞ Bootstrap methods

Bootstrap method call

Adapting ∞ Method handles

Calling Jump with arguments

Charles NutterJRuby Lead, Red Hat

“Invokedynamic is the most important addition to Java in years. It will change the face of the platform.”

Agenda

Building the future

Loose ends in the Java 7 API

Method handle introspection (reflection) Generalized proxies (more than single-method intfs) Class hierarchy analysis (override notification) Smaller issues:

– usability (MethodHandle.toString, polymorphic bindTo)

– sharp corners (MethodHandle.invokeWithArguments)

– repertoire (tryFinally, more fold/spread/collect options)

Integration with other APIs (java.lang.reflect)

Support for Lambda in OpenJDK8

More transforms for SAM types (as needed). Faster bindTo operation to create bound MHs

– No JNI calls.

– Maybe multiple-value bindTo.

Faster inexact invoke (as needed).

Let’s continue building our “future VM”

Da Vinci Machine Project: an open source incubator for JVM futures

Contains code fragments (patches). Movement to OpenJDK requires:

– a standard (e.g., JSR 292)

– a feature release plan (7 vs. 8 vs. ...)

bsd-port for developer friendliness. mlvm-dev@openjdk.java.net

http://hg.openjdk.java.net/mlvm/mlvm/hotspot/

Current Da Vinci Machine Patches

MLVM patches

meth method handles implementation

indy invokedynamic

coro light weight coroutines (Lukas Stadler)

inti interface injection (Tobias Ivarsson)

tailc hard tail call optimization (Arnold Schwaighofer)

tuple integrating tuple types (Michael Barker)

hotswap online general class schema updates (Thomas Wuerthinger)

anonk anonymous classes; light weight bytecode loading

Caveat: Change is hard and slow

Hacking code is relatively simple. Removing bugs is harder. Verifying is difficult (millions of users). Integrating to a giant system very hard.

– interpreter, multiple compilers

– managed heap (multiple GC algos.)

– debugging, monitoring, profiling machinery

– security interactions

Specifying is hard (the last 20%...). Running process is time-consuming.

(especially the “last 20%”)

JVM: A Platform for Multiple Languages

Documents

Transcript of JVM: A Platform for Multiple Languages

Patterns for JVM languages - Geecon 2014

Charles nutter star techconf 2011 - jvm languages

JVM ecosystem languages and the future of JVM

New Languages on the JVM - OpenJDKopenjdk.java.net/projects/mlvm/pdf/LangNet20080128.pdf · 21 Are we re-inventing the world? • No, we are adapting classic ideas to the JVM. > In

JavaOne 2012 CON3978 Scripting Languages on the JVM

The Adventurous Developers Guide to JVM Languages

Towards JVM Dynamic Languages Toolchain

Multiple Languages

New Languages on the JVM · • Evolutionary adaptation of the present JVM • Open-ended experimentation on Sun's Hotspot > wild ideas are considered, but must prove useful > while

JVM, byte codes & jvm languages

Bridging multiple API description languages with Restlet

Performance Comparison JVM Languages

BabelMeSH Searching PubMed in Multiple Languages.

Staying Sane While Publishing in Multiple Languages Across Multiple Formats

Languages on the JVM - Groovy, Ruby, Scala, Clojure

JVM & ClassLoaser - 50001.com · english. french. target() target() target() target() JVM & ClassLoader. static. JVM & ClassLoader. JVM & ClassLoader

Patterns for JVM languages JokerConf

Building Languages for the JVM - StarTechConf 2011

Altran presentation in Java & JVM languages conference in Barcelona

A Dynamic Programming Language for the JVM · Java/JVM is language + platform • Not the original story, but other languages for JVM always existed, now embraced by Sun • JVM has