1. JDK7: Improved support for dynamic
languages
Sander Mak
Info Support
Wednesday, November 11, 2009
2. Overview
• JVM Languages
• Problems for dynamic languages
• MLVM: Multi Language Virtual Machine
• Method handles
• Invokedynamic
• Wrap-up
Wednesday, November 11, 2009
3. 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
Wednesday, November 11, 2009
16. Compiling dynamic languages
Performance
(in fairness: JRuby compares well to Ruby)
Smaller = better for JRuby
Wednesday, November 11, 2009
17. Compiling dynamic languages
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);
}
}
Wednesday, November 11, 2009
18. Compiling dynamic languages
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);
}
}
Wednesday, November 11, 2009
19. Compiling dynamic languages
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
#5; //Method java/util/ArrayList.add:(Ljava/lang/
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
#7; //Method java/util/Collections.sort:(Ljava/util/
List;)V
26:
return
Wednesday, November 11, 2009
20. Compiling dynamic languages
At the callsites!
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
#5; //Method java/util/ArrayList.add:(Ljava/lang/
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
#7; //Method java/util/Collections.sort:(Ljava/util/
List;)V
26:
return
Wednesday, November 11, 2009
21. Compiling dynamic languages
At the callsites!in JVM
Invocation
Bytecode
Bytecode Example
0:
new
#2; //class java/util/ArrayList
3:
dupinvokestatic Collections.sort(list)
4:
invokespecial
#3; //Method java/util/ArrayList."<init>":()V
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
#5; //Method java/util/ArrayList.add:(Ljava/lang/
Object;)Z invokespecial constructor call, i.e.: new ArrayList()
14:
pop
15:
aload_1
16:
ldc
#6; //String Pete
18:
invokevirtual
#5; //Method java/util/ArrayList.add:(Ljava/lang/
Object;)Z
21:
pop
22:
aload_1
23:
invokestatic
#7; //Method java/util/Collections.sort:(Ljava/util/
List;)V
26:
return
Wednesday, November 11, 2009
22. Compiling dynamic languages
• 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 fixed, no relinking
Wednesday, November 11, 2009
23. Compiling dynamic languages
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
Wednesday, November 11, 2009
26. Compiling dynamic languages
• Common solutions:
- Don’t compile, interpret (sometimes
unavoidable)
- AOT compilation into specialized invoker
classes (suitable for core methods)
- AOT compilation, then use reflection (for user
defined types)
- JIT bytecode generation of small stub methods
Either way: abundance of synthetic types and
bytecode hard to optimize for JVM
Wednesday, November 11, 2009
27. 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
Wednesday, November 11, 2009
28. 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’)
Wednesday, November 11, 2009
29. 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
Wednesday, November 11, 2009
30. Method handles
• Lightweight, safe method pointers
• Like java.lang.reflect.Method, but:
– No argument boxing/unboxing
– Access checks only at creation time
– Leaner, and as fast as direct call
– No wrapping of exceptions
Wednesday, November 11, 2009
31. Method handles
• Lightweight, safe method pointers
• Like java.lang.reflect.Method, but:
– No argument boxing/unboxing
– Access checks only at creation time
– Leaner, and as fast as direct call
– 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”)
Wednesday, November 11, 2009
32. Method handles
• Lightweight, safe method pointers
• Like java.lang.reflect.Method, but:
– No argument boxing/unboxing
– Access checks only at creation time
– Leaner, and as fast as direct call
– No wrapping of exceptions
Bytecode
59:
aload
4
61:
invokevirtual
#11;
//Method java/dyn/MethodHandle.invoke:(I;Ljava/
lang/String;)Ljava/lang/String
Wednesday, November 11, 2009
33. Method handles
• Instance methods: first arg is receiver
Wednesday, November 11, 2009
34. Method handles
• Instance methods: first 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...
Wednesday, November 11, 2009
35. 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
Wednesday, November 11, 2009
36. 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
Wednesday, November 11, 2009
37. 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
Wednesday, November 11, 2009
38. 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));
Wednesday, November 11, 2009
39. 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));
Wednesday, November 11, 2009
40. 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));
Wednesday, November 11, 2009
41. 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
Wednesday, November 11, 2009
42. JSR-292
So what do dynamic languages want?
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
Wednesday, November 11, 2009
43. JSR-292
So what do dynamic languages want?
Binding MH is a flexible, 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
Wednesday, November 11, 2009
44. 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?
Wednesday, November 11, 2009
49. Invokedynamic - bootstrap
• 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
}
Wednesday, November 11, 2009
50. Invokedynamic - bootstrap
• 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
}
Wednesday, November 11, 2009
51. Invokedynamic - bootstrap
• 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
}
Wednesday, November 11, 2009
52. Invokedynamic - bootstrap
• 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
CallSite is }
bootstrap( .. ) { sub-classable
..lookup..
return CallSite
MH can be guarded
}
with test
Wednesday, November 11, 2009
53. Invokedynamic - bootstrap
• CallSite immutable, except for target
• After installing target, invokedynamic invokes MH
directly
DynamicInvokerClass ImplementationClass
aload_1;
invokedyn. meth:Type; Method implementation(Type) {
return; Handle(s) result = ..
return result
}
CallSite target
bootstrap( .. ) { may be changed
..lookup..
return CallSite later!
}
Wednesday, November 11, 2009
54. 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
Wednesday, November 11, 2009
55. 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
Wednesday, November 11, 2009
56. 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
Wednesday, November 11, 2009
57. 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.
Wednesday, November 11, 2009
58. 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
Wednesday, November 11, 2009
59. JSR-292
So what do dynamic languages want?
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
Wednesday, November 11, 2009
60. 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
Wednesday, November 11, 2009
61. 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 fibonacci testcase
• JDK7 due 1st quarter 2010
Wednesday, November 11, 2009
* Groot deel tijd kijken naar probleem wat opgelost ipv alleen naar &#x2018;coole nieuwe features&#x2019; kijken
* Nadruk niet op API details, zijn nog in ontwikkeling
* gaan ook niet de discussie aan of dynamische talen beter/slechter zijn, het is een gegeven.
* First: just Java, interpreted, grew into optimizing JIT compiler
* Java language/platform was extended many times though JVM bytecode format nearly unchanged
* However JVM grew very mature (JIT, optimize/deoptimize)
* Dynamic language: hard to define, but here: dynamically typed languages like Ruby/Python, with strong meta-programming
* Java language/platform was extended many times though JVM bytecode format nearly unchanged
* However JVM grew very mature (JIT, optimize/deoptimize)
(same is going on for the .Net CLR)
* Dynamic language: hard to define, but here: dynamically typed languages like Ruby/Python, with strong meta-programming
* Java language/platform was extended many times though JVM bytecode format nearly unchanged
* However JVM grew very mature (JIT, optimize/deoptimize)
(same is going on for the .Net CLR)
* Dynamic language: hard to define, but here: dynamically typed languages like Ruby/Python, with strong meta-programming
* Java language/platform was extended many times though JVM bytecode format nearly unchanged
* However JVM grew very mature (JIT, optimize/deoptimize)
(same is going on for the .Net CLR)
* Dynamic language: hard to define, but here: dynamically typed languages like Ruby/Python, with strong meta-programming
* Java language/platform was extended many times though JVM bytecode format nearly unchanged
* However JVM grew very mature (JIT, optimize/deoptimize)
(same is going on for the .Net CLR)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
Interessante ontwikkeling is dat Sun dit steunt (JavaFX, maar ook JRuby/Jython)
Waarom zoveel talen? Ze bieden allemaal hun eigen &#x2018;werkelijkheid&#x2019; (volgende slide)
* Java (taal) bevat ook ficties!
* Schoen gaat wringen wanneer language fictions realiteit van JVM moeten gaan verbergen/opleuken
* Zelfs in Java (Generics) is dat merkbaar... dat is waar tradeoffs (snelheid/bruikaarheid/correctheid) ontstaan
Focus on JRuby in this pres. since very active in JSR-292
* Java (taal) bevat ook ficties!
* Schoen gaat wringen wanneer language fictions realiteit van JVM moeten gaan verbergen/opleuken
* Zelfs in Java (Generics) is dat merkbaar... dat is waar tradeoffs (snelheid/bruikaarheid/correctheid) ontstaan
Focus on JRuby in this pres. since very active in JSR-292
* Java (taal) bevat ook ficties!
* Schoen gaat wringen wanneer language fictions realiteit van JVM moeten gaan verbergen/opleuken
* Zelfs in Java (Generics) is dat merkbaar... dat is waar tradeoffs (snelheid/bruikaarheid/correctheid) ontstaan
Focus on JRuby in this pres. since very active in JSR-292
The language benchmark game (combinatie benchmarks, zeer veel talen te vergelijken)
The language benchmark game (combinatie benchmarks, zeer veel talen te vergelijken)
The language benchmark game (combinatie benchmarks, zeer veel talen te vergelijken)
* Primitives have typed operations, locals are untyped, stack
* Method call bytecodes very close to Java Language, only overloading and generics are solved in javac
* Linking and method selection very rigid: exact matching, no adaptation
* locals can by untyped, stack manipulation largely untyped, treating everything as object goes a long way
* except for method calls!
* JVM bytecode verifier locks everything down as well
Also, not even an enclosing type (class), just a script
*&#x2018;Java&#x2019; objects must be converted to IRubyObject
* Java objects on Heap for JRuby programs are &#x2018;bags of methods&#x2019;
* for core types specialized invokers may be packaged with ruby (but: wasteful, 100s of small classes)
* Started 2007/2008
* Open-ended experiment from Sun. Wild ideas considered, but must prove useful to reach Java SE 7
We are extending the JVM with first-class&#xA0;architectural support for languages other than Java, especially dynamic languages.
Again, we focus on improving call speed. There are many other wishes (some may even be granted), but this one is really important for performance
* Signature polymorphism (there is no actual invoke method conforming to the MethodType)
* results in invokevirtual call on MethodHandle class, which then dispatches to the correct code (if type sig matches!)
* pass target object as first param when virtual method is concerned
* Signature polymorphism (there is no actual invoke method conforming to the MethodType)
* results in invokevirtual call on MethodHandle class, which then dispatches to the correct code (if type sig matches!)
* pass target object as first param when virtual method is concerned
* Signature polymorphism (there is no actual invoke method conforming to the MethodType)
* results in invokevirtual call on MethodHandle class, which then dispatches to the correct code (if type sig matches!)
* pass target object as first param when virtual method is concerned
PermGen space is safe again!
proof-of-concept van JDK ontwikkelaar. Bytecode generatie moet een laatste redmiddel blijven!
voorbeeld: &#x2018;lambda&#x2019;s bouwen met builder pattern&#x2019; en direct invoken (soort DLR expression tree!)
example uses ASM bytecode AST builder
PermGen space is safe again!
proof-of-concept van JDK ontwikkelaar. Bytecode generatie moet een laatste redmiddel blijven!
voorbeeld: &#x2018;lambda&#x2019;s bouwen met builder pattern&#x2019; en direct invoken (soort DLR expression tree!)
example uses ASM bytecode AST builder
PermGen space is safe again!
proof-of-concept van JDK ontwikkelaar. Bytecode generatie moet een laatste redmiddel blijven!
voorbeeld: &#x2018;lambda&#x2019;s bouwen met builder pattern&#x2019; en direct invoken (soort DLR expression tree!)
example uses ASM bytecode AST builder
PermGen space is safe again!
proof-of-concept van JDK ontwikkelaar. Bytecode generatie moet een laatste redmiddel blijven!
voorbeeld: &#x2018;lambda&#x2019;s bouwen met builder pattern&#x2019; en direct invoken (soort DLR expression tree!)
example uses ASM bytecode AST builder
Static typing, static call sites
vs
Dynamic typing, very late binding (typechecks at runtime), eval&#x2019;ing code (only possible by reflection, or interpretation).
Static typing, static call sites
vs
Dynamic typing, very late binding (typechecks at runtime), eval&#x2019;ing code (only possible by reflection, or interpretation).
Static typing, static call sites
vs
Dynamic typing, very late binding (typechecks at runtime), eval&#x2019;ing code (only possible by reflection, or interpretation).
This was already possible (hence the existing JVM languages), but is now architecturally supported. Therefore: easier to implement, more speed through optimizations etc.