JDK7: Improved support for dynamic languages

JDK7: Improved support for dynamic
languages

Sander Mak
Info Support

Wednesday, November 11, 2009

Overview

• JVM Languages
• Problems for dynamic languages
• MLVM: Multi Language Virtual Machine
• Method handles
• Invokedynamic
• Wrap-up


The Java Platform

The JVM has become a complex beast...
1.0 1996
1.1
1.2
1.3
1.4
1.5
1.6 2009

• Performance
• Binary compatibility
• Safety
• Platform independence

The Java Platform


The Java Platform

Java language
JVM

Java libraries


The Java Platform

• More expressiveness:
– ‘Pure’ OO Java
JRuby
– Blocks/Closures/ Scala
JVM
Higher order functions Groovy

– Dynamic typing Clojure

– Metaprogramming JavaFX

Java libraries
• Proven VM
• Interop with Java ‘legacy’

JVM Languages

Java


JVM Languages

Groovy Clojure

JRuby Java JavaFX
Scala


JVM Languages
jProlog Pizza MultiJava
Fan

JLog
Groovy Clojure MetaJ

JRuby Java JavaFX Jaskell

Rhino Scala JBasic
Aardappel
Funnel
Jacl Drools
Jython

JVM Languages

240+
Languages

JVM Languages

‘Language
ﬁctions’
JVM

Exceptions
Primitive types
Objects
Access control
Garbage coll.
Threading
Memory model


JVM Languages

‘Language
ﬁctions’
Java

Enums
Checked exc.
JVM Generics

Exceptions Exceptions
Primitive types Primitive types
Objects Objects
Access control Access control
Garbage coll. Garbage coll.
Threading Threading.
Memory model Memory model


JVM Languages
JRuby

‘Language Open classes
Dynamic typing

ﬁctions’
Java Closures

Enums Enums
Checked exc. Checked exc.
JVM Generics Generics

Exceptions Exceptions Exceptions
Primitive types Primitive types Primitive types
Objects Objects Objects
Access control Access control Access control
Garbage coll. Garbage coll. Garbage coll.
Threading Threading. Threading
Memory model Memory model Memory model


Compiling dynamic languages

Performance

Smaller = better for Java



Performance
(in fairness: JRuby compares well to Ruby)

Smaller = better for JRuby



First: statically typed Java

Java
public class Test {
public static void main(String[] args) {
ArrayList<String> names =
new ArrayList<String>();
names.add("John");
names.add("Pete");
Collections.sort(names);
}
}



Java
public class Test {
public static void main(String[] args) {
ArrayList<String> names =
new ArrayList<String>();
names.add("John");
names.add("Pete");
Collections.sort(names);
}
}


Where are the types?
Bytecode
0:
new
#2; //class java/util/ArrayList
3:
dup
4:
invokespecial
#3; //Method java/util/ArrayList."<init>":()V
7:
astore_1
8:
aload_1
9:
ldc
#4; //String John
11:
invokevirtual
#5; //Method java/util/ArrayList.add:(Ljava/lang/
Object;)Z
14:
pop
15:
aload_1
16:
ldc
#6; //String Pete
18:
invokevirtual
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
#7; //Method java/util/Collections.sort:(Ljava/util/
List;)V
26:
return


At the callsites!
Bytecode
0:
new
3:
dup
4:
invokespecial
7:
astore_1
8:
aload_1
9:
ldc
#4; //String John
11:
invokevirtual
Object;)Z
14:
pop
15:
aload_1
16:
ldc
#6; //String Pete
18:
invokevirtual
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
List;)V
26:
return


At the callsites!in JVM
Invocation
Bytecode
Bytecode Example
0:
new
3:
dupinvokestatic Collections.sort(list)
4:
invokespecial
7:
astore_1
invokevirtual list.add(element) list :: java.util.ArrayList
8:
aload_1
9:
ldc
#4; //String John
invokeinterface list.add(element) list :: java.util.List
11:
invokevirtual
Object;)Z invokespecial constructor call, i.e.: new ArrayList()
14:
pop
15:
aload_1
16:
ldc
#6; //String Pete
18:
invokevirtual
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
List;)V
26:
return



• JVM ‘more dynamic’ than Java
• Exception: method calls
– Signature at callsite must match exactly
TargetClass Name Method descriptor
18:
invokevirtual
#5; //Method java/util/ArrayList.add:(Ljava/lang/Object;)Z

– Dispatch on static type of call and
dynamic type of receiver
– Method must exist at compile time
– Link to target is ﬁxed, no relinking


Again, where are the types?
JRuby
names = ["John", "Pete"]
puts names.sort

• Type inference not feasible
• Types may be constructed @ runtime
• Types may change @ runtime
• Invocation of closures constructed @ runtime


Compiling 2 lines of JRuby ...
... yields >80 bytecode instructions
Bytecode
public class Test_dot_ruby extends org/jruby/ast/executable/AbstractScript {

public <init>()V
ANEWARRAY org/jruby/runtime/CallSite
ICONST_1
LDC "sort"
INVOKESTATIC Test_dot_ruby.setCallSite ([Lorg/jruby/runtime/CallSite;ILjava/lang/String;)[Lorg/jruby/
runtime/CallSite;
ICONST_0
LDC "puts"
INVOKESTATIC Test_dot_ruby.setFunctionalCallSite ([Lorg/jruby/runtime/CallSite;ILjava/lang/String;)
[Lorg/jruby/runtime/CallSite;
PUTFIELD Test_dot_ruby.callSites : [Lorg/jruby/runtime/CallSite;
ALOAD 0
ICONST_2
INVOKEVIRTUAL Test_dot_ruby.initStrings (I)[Lorg/jruby/util/ByteList;
LDC 1
LDC "Pete"
INVOKESTATIC org/jruby/ast/executable/AbstractScript.createByteList ([Lorg/jruby/util/ByteList;ILjava/



Compiling 2 lines of JRuby ... details
Method call
... yields >80 bytecode instructions
Lorg/jruby/runtime/builtin/IRubyObject
Bytecode
LDC “sort”
public class Test_dot_ruby extends org/jruby/ast/executable/AbstractScript
{
INVOKESTATIC Test_dot_ruby.setCallSite ...
public <init>()V
ANEWARRAY org/jruby/runtime/CallSite
ICONST_1INVOKEVIRTUAL org/jruby/runtime/CallSite.call
LDC "sort"
...
INVOKESTATIC Test_dot_ruby.setCallSite ([Lorg/jruby/runtime/CallSite;ILjava/lang/String;)[Lorg/jruby/
runtime/CallSite;
ICONST_0 ‘Fat call paths’
LDC "puts"
INVOKESTATIC Test_dot_ruby.setFunctionalCallSite ([Lorg/jruby/runtime/CallSite;ILjava/lang/String;)
[Lorg/jruby/runtime/CallSite;
PUTFIELD Test_dot_ruby.callSites : [Lorg/jruby/runtime/CallSite;
ALOAD 0
ICONST_2
INVOKEVIRTUAL Test_dot_ruby.initStrings (I)[Lorg/jruby/util/ByteList;
LDC 1
LDC "Pete"
INVOKESTATIC org/jruby/ast/executable/AbstractScript.createByteList ([Lorg/jruby/util/ByteList;ILjava/



• Common solutions:
- Don’t compile, interpret (sometimes
unavoidable)
- AOT compilation into specialized invoker
classes (suitable for core methods)
- AOT compilation, then use reﬂection (for user
deﬁned types)
- JIT bytecode generation of small stub methods

Either way: abundance of synthetic types and
bytecode hard to optimize for JVM

MLVM

• Change of direction @ Sun
– Introduction of JavaFX
– Fortress language
– Officially supporting JRuby
– Open sourcing JDK (compiler & VM)
• Still, JVM remains Java-centric

• Enter: the MLVM and JSR-292
Multi Language VM
Da Vinci Machine

MLVM

John Rose @ Sun:
Language implementers know what they want
  (and know how to simulate it with 100x slowdown)  
VM implementers know what VMs can do
  (and know how to make their favorite language sing)

Let's bring them together.

(JSR 292 ‘invokedynamic’)


JSR-292

So what do dynamic languages want?
Binding Marker
Delay binding as long Indicate in bytecode
as possible. Hide that a dynamic call
exact destination of should be made
call @ compiletime

Adaptation
Language should be
able to implement its
own coercion rules
when matching type
signatures


Method handles

• Lightweight, safe method pointers
• Like java.lang.reﬂect.Method, but:
– No argument boxing/unboxing
– Access checks only at creation time
– Leaner, and as fast as direct call
– No wrapping of exceptions


Method handles

– No wrapping of exceptions Java 7
MethodHandle mh = MethodHandles.lookup().findStatic(
Enclosing.class, “methodName”,
MethodType.make(String.class, int.class,
String.class) )
mh.<String>invoke(1, “2”)


Method handles

– No wrapping of exceptions
Bytecode
59:
aload
4
61:
invokevirtual
#11;
//Method java/dyn/MethodHandle.invoke:(I;Ljava/
lang/String;)Ljava/lang/String


Method handles

• Instance methods: ﬁrst arg is receiver


Method handles

• Instance methods: ﬁrst arg is receiver
Java 7
MethodHandle mh = MethodHandles.lookup().findVirtual(
Enclosing.class, “methodName”,
MethodType.make(String.class, int.class,
String.class)
)
mh.<String>invoke(receiver, 1, “2”)

• Receiver may be pre-bound to MH
• Faster than normal ‘invokevirtual’!
• Method Handles prepare for closures...

Method handles

• Immutable: MH has one function type
• Signature polymorphism for invoke
• Can be composed and/or adapted:
– Add or drop arguments
– Guard with test
– Convert arguments

JVM ‘knows’ Method Handles:
• Can inline (chains of) method handles

Method handles

• Immutable: MH has one function type
MH Chain example: Test MH

• Signature polymorphism for invoke
Guard
Originalcomposed and/or adapted:
• Can be Insert
with Success MH
MH arg.
test
– Add or drop arguments
– Guard with test
Fallback MH
mh.invoke(..)
– Convert arguments

JVM ‘knows’ Method Handles:
• Can inline (chains of) method handles

Anonymous classloading

Create unnamed classes from byte[]
• Garbage collectible
Class not in system dictionary, Class.forName() won’t work

• Inherit access & security from host
Host class is caller of Anon. classloader

• Create patchable template classes
Specialize classes by patching constant pool @ loadtime

Vastly improves runtime code generation

Anonymous classloading
Java 7
Create unnamed classes from byte[]
MethodType methodType = MethodType.make(int.class,
• Garbage collectible
int.class, int.class);
Class not in system dictionary, Class.forName() won’t work
ExprBuilder builder = new ExprBuilder(methodType);
• Inherit access & security from host
Var a = builder.parameter(0);
Var b = builder.parameter(1);
Host class is caller of Anon. classloader
builder.
• Create patchable template classes
load(a).
load(b).
Specialize classes by patching constant pool @ loadtime
add();

MethodHandle mh =
builder.createMethodHandle(Main.class);
Vastly improves runtime code generation
System.out.println(mh.invoke(2, 3));

JSR-292


Adaptation MH can be chained to add
Language should be
able to implement its custom conversion rules
own coercion rules
when matching type
signatures Argument list can be
adjusted


JSR-292


Binding MH is a ﬂexible, adaptable
Delay binding as long
as possible. Hide
pointer to methods
exact destination of
call @ compiletime
Invocation overhead low

Invocation binds directly to
single method handle

Invokedynamic

New bytecode, last piece of JSR-292 puzzle:
Name Method descriptor
18:
invokedynamic
#5; //NameAndType addInts:(II)I

• Invocation without reference to actual
method descriptor
• Instead, symbolic name and type
• No receiver: all arguments are equal

What is the target?

Invokedynamic - bootstrap

Bootstrap method receives dynamic calls
Java 7
static {
Linkage.registerBootstrapMethod(
"bootstrapID");
}

static CallSite bootstrapID(Class<?> callerClass,
String methodName, MethodType methodType) {
MethodHandle target = ..
CallSite site = new CallSite(callerClass,
methodName, methodType);
site.setTarget(target);
return site;
}



• CallSite immutable, except for target
• After installing target, invokedynamic invokes MH
directly
DynamicInvokerClass ImplementationClass

aload_1;
invokedyn. meth:Type; implementation(Type) {
return; result = ..
return result

}

bootstrap( .. ) {
..lookup..
return CallSite

}



directly

aload_1;
invokedyn. meth:Type; implementation(Type) {
return; result = ..
return result

CallSite is }

bootstrap( .. ) { sub-classable
..lookup..
return CallSite
MH can be guarded
}
with test


directly

aload_1;
invokedyn. meth:Type; Method implementation(Type) {
return; Handle(s) result = ..
return result

}
CallSite target
bootstrap( .. ) { may be changed
..lookup..
return CallSite later!
}


Project coin: JSR-292 syntax
Java 7
import java.dyn.*;

public class HelloSimple {
public static void main(String... args) {
greeter.<void>invoke(args[0]); // Direct MH
InvokeDynamic.sayIt(args[0]); // invokedynamic
}

public static void greeter(String x) { .. println }

static MethodHandle greeter
= MethodHandles.lookup().findStatic(
Hello.class, "greeter",
MethodType.make(void.class, String.class));

// bootstrap: link “sayIt” to greeter MH


Invokedynamic

• Invokedynamic + bootstrap method
allow language to up-call from VM to
custom code for linking/calling.

Not impossible before, but hard and slow.
JVM now fully optimizes dynamic calls.


JSR-292

Marker

invokedynamic bytecode Indicate in bytecode
that a dynamic call
should be made

Binding
bootstrap mechanism and Delay binding as long
as possible. Hide
method handles exact destination of
call @ compiletime


Wrap-up

• JSR-292 invokedynamic features:
– Language implementors can avoid tricks
– Level the playing ground, speedwise
– Allow existing VM optimizations to be
applied to new paradigms
• JSR292/invokedynamic will be
backported


Wrap-up

• JRuby, Groovy actively working on
JSR-292 support
• For example, JRuby can cut 80% of
linking/calling code in runtime
• Unfortunately no real benchmarks, but:
– Surinx preliminary testing: up to 5-fold
increase on naive ﬁbonacci testcase
• JDK7 due 1st quarter 2010

Questions


JDK7: Improved support for dynamic languages

More Related Content

Viewers also liked

Similar to JDK7: Improved support for dynamic languages

More from Sander Mak (@Sander_Mak)

Recently uploaded

JDK7: Improved support for dynamic languages

Editor's Notes