Jvm Language Summit Rose 20081016

The JVM Language Summit:

Many Languages, One Machine

John R. Rose, Sr. Staff Engineer
john.rose@sun.com
http://blogs.sun.com/jrose

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

Copyright Sun Microsystems, Inc 2008: 2

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
Bernd Mathiske, Sun

http://wiki.jvmlangsummit.com/MaxineVM

Run Your
Fortress: Run your whiteboard
White Board
ProjectFortress: run your whiteboard, in parallel, on the JVM

Many opportunities for parallelism
David Chase, Sun

vnorm = v/ v
k Aggregate objects and
ak x reductions drive parallelism
k←1:n with “generators”.

C =A∪B Operands are
evaluated in
parallel.
y = 3x sin x cos 2x log log x
http://wiki.jvmlangsummit.com/Fortress
Page 5

Laptop – 1, Rose & Goetz – 0


Day Two Highlights


Ask the man with the MOP…

MOP summary:
we have...
Attila Szegedi, Adeptra

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

http://wiki…/DynamicLanguageMOP

Clojure: Not your granddad’s Lisp
Atomic Update
Rich Hickey, Clojure.org

foo :a quot;fredquot;
:b quot;ethelquot;
:c 42
:d 17
:e 6

@foo
Structural sharing
:a quot;lucyquot;
:b quot;ethelquot;

• Always coordinated
:c 42
:d 17

• Multiple semantics
:e 6

• Next dereference sees new value
• Consumers of values unaffected
http://wiki.jvmlangsummit.com/Clojure

Day Three Highlights


The view from Redmond

!quot;#$%!&$'()$#quot;)*+
Mads Torgersen, Microsoft

! !quot;##$%&'(%$)quot;)*($quot;$+(#(,quot;'($-*&)*$+.(%$'*($
+&%/quot;')*
! 0#.-$/quot;'*$&%$1)quot;##(23$#quot;4,5quot;,($%/()&6&)7$89/&)quot;##9
:3 ;%<$'*($2()(&=(2$.>?()'$&6$&'$-quot;4'%$'.$#..<5/
@3 A6$4.'B$5%($#quot;4,5quot;,($>&4+&4,$25#(%$.4$254'&C($'9/(
D3 E&'*(2$-quot;9B$2('524$!quot;#$ quot;4+$%$&'(') E8%
F3 Gquot;')*$5/$+&%/quot;')*$E8$$-&'*$4(-$)quot;%(
H3 !.C/&#($E8$quot;4+$&4%'quot;##$&4$)quot;##$%&'(

http://wiki…/BehindLINQ

Java: Still the common language?

!quot;#$%&$'($)&*&+,$
Neal Gafter, Microsoft

•! -''$.(//(#$0quot;#12quot;1&$3"42+&5$4($6quot;7quot;$
–! 89#quot;/:.$/&4;('$':5<quot;4.;$
–! =+(<&+$4quot;:0$.quot;005$
–! >:.;$:'&#?@&+5$A&B1B$CDEF$
–! G&9%(+'$<quot;+quot;/&4&+5$
–! Hquot;11&'I&J4&#'&'$#2/&+:.5$
–! !quot;#$%quot;&'()*'++,-.+$
–! !(#?#2quot;?(#5$

http://wiki…/JVMClosures

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

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

Recomendados

Recomendados

Más contenido relacionado

Similar a Jvm Language Summit Rose 20081016

Similar a Jvm Language Summit Rose 20081016 (20)

Más de Eduardo Pelegri-Llopart

Más de Eduardo Pelegri-Llopart (20)

Último

Último (20)

Jvm Language Summit Rose 20081016