Jvm Language Summit Rose 20081016

The JVM Language Summit:

Many Languages, One Machine

John R. Rose, Sr. Staff Engineer [email protected] http://blogs.sun.com/jrose

2 Copyright Sun Microsystems, Inc 2008:

How language & VM geeks party

•  January 2008: Sun engineers Brian Goetz, Charlie Nutter, Dan Ingalls, & John Rose visit and thoroughly enjoy 3 days in Redmond at Microsoft’s Lang.NET conference.

•  March 2008: Brian says to John et al, “Why don’t we do one of those at Sun for the JVM?”

•  September 2008: ~80 key VM and language designers meet in Santa Clara for 3 exhilarating days, discussing the future of their projects. (Microsoft colleagues returned the visit!)


Handout for JavaOne, May 5-9

Guerrilla marketing at its finest:


JVM Language Summit 2008

http://jvmlangsummit.com

From the website:


VMs represented by attendees

•  Sun HotSpot*, Maxine*, Monty •  Oracle JRockit •  IBM J9 •  Azul HotSpot* •  Microsoft CLR* •  Parrot VM* * marks a presentation


JVM languages presented

•  Java (Gosling keynote) •  Lisps: Common Lisp (Jatha), Scheme, Clojure •  Scripting: Groovy, JRuby, Jython, PHP, Rexx •  Assembler: ASM, Kawa •  JavaFX •  Scala •  Fortress


Day One Highlights


Maxine: The JVM that hosts itself

http://wiki.jvmlangsummit.com/MaxineVM

Ber

nd M

athi

ske,

Sun


Page

ProjectFortress: run your whiteboard, in parallel, on the JVM

Many opportunities for parallelism

5

Run YourWhite Board

vnorm = v/ !v!!

k!1:nak xk

C = A "B

y = 3x sin x cos 2x log log x

in Parallel!

ProjectFortress.sun.com

Aggregate objects and reductions drive parallelism with “generators”.

Operands are evaluated in parallel.

Fortress: Run your whiteboard

http://wiki.jvmlangsummit.com/Fortress

Dav

id C

hase

, Sun


Laptop – 1, Rose & Goetz – 0


Day Two Highlights


MOP summary:we have...

• Protocol for language independent property access on objects and for invocation of methods,

• designed for composability,

• Factory that builds an optimized composite MOP from all MOPs available to a class loader,

• MOP for POJOs, usable as a fallback when no other MOP matches. Handles overloaded methods, varargs, type conversions,

Ask the man with the MOP…

http://wiki…/DynamicLanguageMOP

Atti

la S

zege

di, A

dept

ra


Atomic Update

6

17

"ethel"

"fred"

42

:e

:d

:c

:b

:a

6

17

"ethel"

"lucy"

42

:e

:d

:c

:b

:a

foo

@foo

• Always coordinated

• Multiple semantics

• Next dereference sees new value

• Consumers of values unaffected

Structural sharing

Clojure: Not your granddad’s Lisp

http://wiki.jvmlangsummit.com/Clojure

Ric

h H

icke

y, C

loju

re.o

rg


Day Three Highlights


!"#$%!&$'()$#")*+

! !"##$%&'(%$)")*($"$+(#(,"'($-*&)*$+.(%$'*($

+&%/"')*

! 0#.-$/"'*$&%$1)"##(23$#"4,5",($%/()&6&)7$89/&)"##9

:3 ;%<$'*($2()(&=(2$.>?()'$&6$&'$-"4'%$'.$#..<5/

@3 A6$4.'B$5%($#"4,5",($>&4+&4,$25#(%$.4$254'&C($'9/(

D3 E&'*(2$-"9B$2('524$!"#$ "4+$%$&'(') E8%

F3 G"')*$5/$+&%/"')*$E8$$-&'*$4(-$)"%(

H3 !.C/&#($E8$"4+$&4%'"##$&4$)"##$%&'(

The view from Redmond

http://wiki…/BehindLINQ

Mad

s To

rger

sen,

Mic

roso

ft


!"#$%&$'($)&*&+,$

•! -''$.(//(#$0"#12"1&$3&"42+&5$4($6"7"$

–!89#"/:.$/&4;('$':5<"4.;$

–!=+(<&+$4":0$."005$

–!>:.;$:'&#?@&+5$A&B1B$CDEF$

–!G&9%(+'$<"+"/&4&+5$

–!H"11&'I&J4&#'&'$#2/&+:.5$

–!!"#$%"&'()*'++,-.+$

–!!(#?#2"?(#5$

Java: Still the common language?

http://wiki…/JVMClosures

Nea

l Gaf

ter,

Mic

roso

ft


Beyond the prepared talks…

Key conversations: •  design and usage of invokedynamic •  metaobject protocols •  language interoperability •  platform (bytecode, library) design •  immutable data structures


The tale of invokedynamic

Rob Nicholson Fredrik Öhrström Rémi Forax

John Rose Jochen Theodorou Tom Enebo Charlie Nutter

Attila Szegedi


While we’re at the hardware store…

•  too many little classes (need relief in packaging and/or loading)

•  new method linkage or dispatch

•  tagged primitives

•  guaranteed tail-call optimization

•  interface injection

•  continuations

•  interpreter vs. bytecodes, byte compiler vs. JIT (need graceful mixed mode)

•  naked native methods

•  strange arrays (arrays of tuples, etc.)

•  a fast numeric tower, rational arithmetic

•  floating point rounding modes


My own take-aways

•  invokedynamic – sound design, exposition needs work

•  synergy: JSR 292 with Attila Szegedi’s MOP •  Interface injection is going to be helpful. •  Tailcall and value types will never go away. •  Innovation on the JVM is a requirement. •  We have to do another Summit next year.

http://blogs.sun.com/jrose/entry/view_from_the_summit


Pizza with extra MOP


Results


Results

•  Average conference ratings 4.4 – 4.9 out of 5. •  Talk ratings consistently in the 4-5 range. •  Rapid exchange of ideas •  New partnerships among a who’s who of leaders •  A better sense of our shared future

See also: http://blogs.sun.com/jrose/entry/view_from_the_summit


Results

•  …Also, cool T-shirts:


When geeks party, we all win.

•  This meeting was none too soon. •  The JVM is going to be used for more than Java.

(Alternatively, the JVM risks irrelevance.)

•  Let’s take a broader look at the history…


1997–2007

was a great decade...


1997–2007 was a great decade...

...to invent virtual machines

•  CLR-, JVM-based systems have become normal •  CPU cycles are cheap enough for JIT, GC, RTT, ... •  many Java programmers, tools, systems •  much of the Java ecosystem is now open-source

Result: VMs & tools are mature, ubiquitous


Great JVM features

•  flexible online code loading (nice safe bytecodes) •  GC & object schema •  reflective access to classes & objects •  lots of ancillary tools (JMM, JVMTI, dtrace) •  good libraries & a nice language to write more •  optimizing JITs, object- and library-aware •  clever performance techniques:

>  type inference, customization, profiling, deoptimization, fast/slow paths, etc., etc.


The widget that came to stay…


2008–2018:

What shall we build now?


What shall we build now?

•  Smaller devices (phones, cards, motes) •  Bigger data crunchers (many-core, DARPA HPCS) •  Richer presentations (complex immersive models) •  Fancier network protocols (cloud computing) •  Nomadic computations (agents, workflow) •  Mutable or scriptable widgets

All these are easier to engineer when a suitably tuned VM decouples hardware from software.


So, here is a great new decade…

…For more VMs! •  Lightweight VMs for small devices •  Massively parallel VMs for huge problems •  Giant throughput VMs for network computing •  Browser-linked VMs for rich clients •  Etc., etc.

“One Machine” “Common ISA/ABI” Having Java bytecodes and libraries in common gives access to a more tools and platforms.


It is also a great new decade…

…For new languages!

Formal computing languages provide a crucial mediation between programmers and their machines. These languages get tweaked, hacked, and replaced, as programmers scratch what itches…

•  There are dozens of JVM languages http://wikipedia.org/wiki/List_of_JVM_languages

•  One account lists 200 of them! http://robert-tolksdorf.de/vmlanguages.html


What sorts of languages? Each language provides specific modes of

abstraction, decoupling a programmer’s chosen mode of thinking from the details of the machine.

•  Little languages focus on small domains. •  Presentation languages specify visual forms. •  Scripting languages provide informality. •  “Classic” languages access traditional insights. •  Parallel languages concentrate on big data flows. •  Java is a great way to directly program the JVM. •  And sometimes there is a Better Mousetrap.


Languages can reuse the Java VM High level languages often require: •  very late binding (that is, runtime x, for x in

loading, linking, typing, code generation, etc.) •  automatic storage management (GC) •  environmental queries (reflection, stack walking) •  exotic primitives (tailcall, bignums, call/cc) •  robust handling of incorrect or malicious inputs •  helpful runtime support libraries (REs, math, ...) •  a compiler (JIT and/or AOT) that understands it all


Pain Points

•  The JVM is a stronger foundation than C/C++ >  but not quite enough for emerging languages >  Reason: the JVM was made for Java only... >  (historically the x86 was for C and Pascal...)

•  Language implementers still try to reuse the JVM •  Near-misses are experienced as “pain points”


So what's missing?

•  Dynamic invocation

•  And always, higher performance


So what's missing?

•  Dynamic invocation •  Lightweight method objects •  Lightweight bytecode loading •  Continuations and stack introspection •  Tail calls and tail recursion •  Tuples and value-oriented types •  Immediate wrapper types •  Symbolic freedom (non-Java names) •  And always, higher performance

39

the Da Vinci Machine

a multi-language renaissance for the Java™ Virtual Machine architecture

http://openjdk.java.net/ /projects/mlvm/

39


A Solution from Sun

•  Evolutionary adaptation of the present JVM •  Open-ended experimentation on Sun's Hotspot

>  wild ideas are considered, but must prove useful >  while incubating, features are disabled by default

•  Eventual convergence on standards •  Extension of the standard JVM architecture

>  deliberate, measured, careful extension


Da Vinci Machine Project Mission

•  Prototype JVM extensions to run non-Java languages efficiently

•  First-class architectural support (not hacks or side-cars)

•  Complete the existing architecture with general purpose extensions

•  New languages to co-exist gracefully with Java in the JVM


JSR 292 – Dynamic Invocation

•  non-Java call site in the bytecodes

•  language-specific handler >  determines call linkage at runtime >  works in a reflective style >  installs direct (non-reflective) methods

•  stateful: updated or revoked over time •  type-sensitive target method selection

>  based on first argument, all arguments >  or no arguments


JSR 292 – Method handles

•  java.dyn.MethodHandle >  lightweight method reference >  each instance supports just one invoke op >  the signature of the invoke can vary

•  caller invokes knowing method handle signature >  …but not its name or containing class >  signature mismatches cause exceptions

•  call runs at nearly the speed of normal Java call


JSR 292 – Method handles (2)

•  method handles give pluggable access to >  invokestatic/invokespecial >  invokevirtual/invokeinterface >  common conversions (e.g., checkcast) >  curried or “bound” methods >  complex combinators

•  required to glue together dynamic call sites •  requires VM and/or library support for common

adaptation patterns (curry, receiver check, varargs, etc…)


JSR 292 (?) – Interface Injection

•  a structured way to add methods to classes >  some interfaces are “injectable” >  for each class, a handler is called ≤1 times >  the handler’s decision is final >  handler provides method handles as needed

•  can extend the meaning of classes •  e.g, a “Groovy method” on java.lang.String •  or a “Ruby metaobject” on java.lang.Integer •  fast, cheap, lazy, and general; not yet specified


HotSpot – Anonymous classes

•  Faster and more reliable loading and unloading •  Little interaction with system dict. or class

loaders >  (“class names considered harmful”) >  a better way to load ad hoc bytecodes >  not a proposed standard, just an

implementation trick •  Library-directed code customization

>  via constant pool patching


HotSpot – Performance work

•  No-brainer: Support less-static bytecode shapes >  Ongoing for years; see website for fixed bugs >  Examples: Class.isInstance, Arrays.copyOf

•  Faster reflection •  Escape analysis (etc.) to remove auto-boxing •  Maybe: No-heap rep. for java.lang.Integer •  More subtle: Faster closure-like interfaces •  Etc., etc.


Other great VM ideas (which might need community champions)

•  Continuations (cf. Scheme call/cc) active work by Lukas Stadler at JKU, Linz

•  Tail calls (functional languages, threaded code) active work by Arnold Schwaighofer at JKU, Linz

•  Value object (cf. Lisp fixnums) •  Tuple types (cf. .NET structs, Fortress tuples)


Are we re-inventing the world?

•  No, we are adapting classic ideas to the JVM. >  In some cases, exposing mature JVM internals to language

implementers, for the first time. >  In other cases, adjusting JVM architecture to be less Java-

centric.

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

2008–2018:

a great decade

for JVMs

and languages

http://wiki.jvmlangsummit.com

http://openjdk.java.net/projects/mlvm

http://blogs.sun.com/jrose

Jvm Language Summit Rose 20081016

Technology

highlights copyright

comfortress copyright

commaxinevm copyright

scripting languages

presentation languages

little languages

sorts of languages

jvm language summit