JVMLangSummit - User contributions [en]

Rémi Forax (JDart)

2012-07-31T15:51:03Z

Forax: Created page with "== Links == * slides: http://cr.openjdk.java.net/~forax/jvmsummit2012/jvmsummit12.pdf"

== Links ==
* slides: http://cr.openjdk.java.net/~forax/jvmsummit2012/jvmsummit12.pdf

2012 Main Page

2012-07-31T15:49:29Z

Forax: /* Agenda */

__NOTOC__
Welcome to the wiki for the 2012 JVM Language Summit, taking place July 30-August 1, 2012, at the Oracle Santa Clara Campus.

== Links ==

* [http://openjdk.java.net/projects/mlvm/jvmlangsummit JVM Language Summit] main page
* Email contacts: [mailto:brian.goetz-at-oracle.com Brian Goetz] and [mailto:john.r.rose-at-oracle.com John Rose]
* Archived wiki pages: [[2008_Main_Page | 2008]], [[2009_Main_Page | 2009]], [[2010_Main_Page | 2010]], [[2011_Main_Page | 2011]]
* [[Logistics]] page for travel tips and requests
* To gain write access, [[#Self-registration | see instructions below]].

== Agenda ==

{| class="wikitable" style="text-align: center;"
!
!Monday, July 30
!Tuesday, July 31
!Wednesday, August 1
|-
| 8:20
| rowspan="2" style="background-color:#ffc7ce;" | Breakfast
| rowspan="2" style="background-color:#ffc7ce;" | Breakfast
| rowspan="2" style="background-color:#ffc7ce;" | Breakfast
|-
| 8:40
|-
| 9:00
| rowspan="2" style="background-color:#ffeb9c;" |
Georges Saab: Welcome from Oracle
| rowspan="2" style="background-color:#ffeb9c;" |
[[Jaba Batches: A Radical (And Better) New Approach to SQL, RMI, and WS Clients|William Cook (Batches)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[RTalk: a Smalltalk 'Live' Environment Built on the JVM|Mark Roos (RTalk)]]
|-
| 9:20
|-
| 9:40
| rowspan="2" style="background-color:#ffeb9c;" |
[[Lambda Expressions in Java|Brian Goetz (Lambda)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Patterns for Staged Compilation in Java|Matt Fowles (Staged compilation)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[invokedynamic Performance for Groovy|Jochen Theodorou (Groovy)]]
|-
| 10:00
|-
| 10:20
| style="background-color:#ffc7ce;" | Break
| style="background-color:#ffc7ce;" | Break
| style="background-color:#ffc7ce;" | Break
|-
| 10:40
| rowspan="2" style="background-color:#ffeb9c;" |
[[MethodHandle Introspection: Internals|Dan Heidinga (MH introspection)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Truffle: A Self-Optimizing Runtime System|Thomas Wuerthinger (Truffle)]]
| rowspan="2" style="background-color:#ffeb9c;" |
John Rose (Arrays[2.063])
|-
| 11:00
|-
| 11:20
| rowspan="2" style="background-color:#ffeb9c;" |
[[Lambda Forms: IR for Method Handles|John Rose (Lambda Forms)]]
| rowspan="3" style="background-color:#c6efce;" |
[[Truffle Workshop|Lukas Stadler (Truffle)]], 
[[Kawa|Per Bothner (Kawa)]]
| rowspan="3" style="background-color:#c6efce;" |
[[Building a Dynamic Language on the JVM|Mark Roos (RTalk)]], 
[[Working with invokedynamic|Jochen Theodorou (invokedynamic)]]
|-
| 11:40
|-
| 12:00
| rowspan="3" style="background-color:#ffc7ce;" | Lunch
|-
| 12:20
| rowspan="2" style="background-color:#ffc7ce;" | Lunch
| rowspan="2" style="background-color:#ffc7ce;" | Lunch
|-
| 12:40
|-
| 13:00
| rowspan="2" style="background-color:#ffeb9c;" |
[[0xdata|Cliff Click (Big Data)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[7 Features the JVM Should Steal From the CLR|Jeroen Frijters (CLR/JVM)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Project Alchemy: Rebooting a Dynamic Image-based Language with a Large C Runtime|Duncan MacGregor (Migrating to JVM)]]
|-
| 13:20
|-
| 13:40
| rowspan="2" style="background-color:#ffeb9c;" |
[[Datomic|Rich Hickey (Datomic)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Embedding Fortress Types and Dispatch in the JVM|David Chase (Fortress)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Rémi Forax (JDart)]]
|-
| 14:00
|-
| 14:20
| style="background-color:#ffc7ce;" | Break
| style="background-color:#ffc7ce;" | Break
| style="background-color:#ffc7ce;" | Break
|-
| 14:40
| rowspan="2" style="background-color:#ffeb9c;" |
[[The Mesh Language|Basil Hosmer (Mesh)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Multi-tenancy Programming Models|Ryan Sciampacone (Multi-tenant JVM)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Multi-language JDI? You're Joking, Right?|Jim Laskey (JDI)]]
|-
| 15:00
|-
| 15:20
| rowspan="2" style="background-color:#ffeb9c;" |
[[Graal (2012)|Doug Simon (Graal)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[Assembling for the JVM|Michael Wiedeking (AL1 JVM assembler)]]
| rowspan="2" style="background-color:#ffeb9c;" |
[[A Friend in Need Is a Friend Indeed: Kotlin and Java|Andrey Breslav (Kotlin/Java interop)]]
|-
| 15:40
|-
| 16:00
| rowspan="3" style="background-color:#c6efce;" |
[[Mesh Deeper Dive|Basil Hosmer (Mesh)]], 
[[Graal Compiler IR|Gilles Duboscq (Graal)]]
| rowspan="3" style="background-color:#c6efce;" |
[[Java Collections Framework Design|Donald Raab (Collections)]], 
[[Design Discussion for Jaba Batches: A New Approach to SQL, RMI, and WS Clients|William Cook (Batches)]]
| rowspan="3" style="background-color:#c6efce;" |
[[Building on ASM|Duncan MacGregor (ASM)]], 
[[What Kotlin Doesn’t Do and Why|Andrey Breslav (Kotlin)]]
|-
| 16:20
|-
| 16:40
|-
| 17:00
| rowspan="6" |
| rowspan="3" |
| rowspan="6" |
|-
| 17:20
|-
| 17:40
|-
| 18:00
| rowspan="3" style="background-color:#ffc7ce;" | Dinner
|-
| 18:20
|-
| 18:40
|}

== Self-registration ==

In order to upload slides or create and edit wiki pages, you need an account.
# Log in as user [[User:jvmlang|jvmlang]] and with a password which you should have received separately.
# Go to the [http://wiki.jvmlangsummit.com/index.php?title=Special:UserLogin&type=signup user creation page]. (If you have an OpenJDK or java.net user name, please reuse that here.)
# Log out, then back in using your new user name (note the tiny login link at the upper right).

The initial jvmlang participant account does not have full write privileges; please use it only for self-registering.

If you are having trouble recovering your password from last year, just re-register (e.g., ''jrose2'').

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

== Bonus Discussions ==

(add pages and/or workshop links here)
* ...

Why Tailcalls

2010-07-29T16:27:07Z

Forax: /* Reduce call stack size ! */

Are tailcalls fated to come in second place on every feature priority list?

Let's gather the use cases and consider the implementation.

(Note: This page is about "hard tail calls" as defined in the [http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm Rose blog]. Soft TCO is already in many compilers, but does not have a strong effect on software architecture.)

== use cases ==
=== multi-core task distribution ===
(Doug Lea) chaining task execution; without tail calls you blow the stack needlessly

=== languages with guaranteed TCO ===
These are languages with functional patterns, including Scheme, Scala, F#. Seph also aims to give this guarantee.

=== guaranteed disposal of stack-frame ===
Clojure needs workarounds to avoid floating garbage
public static int count(Object o) {
if (o instanceof Counted)
return ((Counted) o).count();
return countFrom(Util.ret1(o, o = null));
}
static public Object ret1(Object ret, Object nil) { return ret; }

=== Reduce call stack size ! ===
(Rémi) Avoid to show language implementation internals by collapsing runtime stack frame.

=== Kōan ===
Tail call... Booty call... More than a coincidence? You decide.

== external links ==
;Proposal: http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm
;Thesis: http://www.ssw.uni-linz.ac.at/Research/Papers/Schwaighofer09Master/
;mlvm Wiki: http://wikis.sun.com/display/mlvm/TailCalls
;mlvm Code: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/tailc.patch

Why Tailcalls

2010-07-29T16:26:31Z

Forax: /* Reduce call stack size ! */

Are tailcalls fated to come in second place on every feature priority list?

Let's gather the use cases and consider the implementation.

(Note: This page is about "hard tail calls" as defined in the [http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm Rose blog]. Soft TCO is already in many compilers, but does not have a strong effect on software architecture.)

== use cases ==
=== multi-core task distribution ===
(Doug Lea) chaining task execution; without tail calls you blow the stack needlessly

=== languages with guaranteed TCO ===
These are languages with functional patterns, including Scheme, Scala, F#. Seph also aims to give this guarantee.

=== guaranteed disposal of stack-frame ===
Clojure needs workarounds to avoid floating garbage
public static int count(Object o) {
if (o instanceof Counted)
return ((Counted) o).count();
return countFrom(Util.ret1(o, o = null));
}
static public Object ret1(Object ret, Object nil) { return ret; }

=== Reduce call stack size ! ===
(Rémi) Avoid to show language implementation internals by colapsing runtime stack frame.

=== Kōan ===
Tail call... Booty call... More than a coincidence? You decide.

== external links ==
;Proposal: http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm
;Thesis: http://www.ssw.uni-linz.ac.at/Research/Papers/Schwaighofer09Master/
;mlvm Wiki: http://wikis.sun.com/display/mlvm/TailCalls
;mlvm Code: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/tailc.patch

Why Tailcalls

2010-07-29T16:26:11Z

Forax: /* use cases */

Are tailcalls fated to come in second place on every feature priority list?

Let's gather the use cases and consider the implementation.

(Note: This page is about "hard tail calls" as defined in the [http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm Rose blog]. Soft TCO is already in many compilers, but does not have a strong effect on software architecture.)

== use cases ==
=== multi-core task distribution ===
(Doug Lea) chaining task execution; without tail calls you blow the stack needlessly

=== languages with guaranteed TCO ===
These are languages with functional patterns, including Scheme, Scala, F#. Seph also aims to give this guarantee.

=== guaranteed disposal of stack-frame ===
Clojure needs workarounds to avoid floating garbage
public static int count(Object o) {
if (o instanceof Counted)
return ((Counted) o).count();
return countFrom(Util.ret1(o, o = null));
}
static public Object ret1(Object ret, Object nil) { return ret; }

=== Reduce call stack size ! ===
(Rémi) Avoid to show language implementation internals by colapsing runtime stack frame.

=== Kōan ===
Tail call... Booty call... More than a coincidence? You decide.

== external links ==
;Proposal: http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm
;Thesis: http://www.ssw.uni-linz.ac.at/Research/Papers/Schwaighofer09Master/
;mlvm Wiki: http://wikis.sun.com/display/mlvm/TailCalls
;mlvm Code: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/tailc.patch

PHP.reboot: a post JSR292 dynamic language

2010-07-28T18:55:28Z

Forax: /* Abstract */

;Speaker: Rémi Forax
;Project: http://code.google.com/p/jvm-language-runtime/

===Abstract===

I will present my new pet project: PHP.reboot a safe and secure PHP like language that run on top of a 1.7 VM. After a short presentation of the language, I will explain its design and how this architecture a REPL interpreter, a runtime compiler with a loop optimizer and the foundation of Eclipse plugin, whole in one.

http://wiki.jvmlangsummit.com/Image:Jvmsummit-phpreboot.pdf

File:Jvmsummit-phpreboot.pdf

2010-07-28T18:54:52Z

Forax: PHP.reboot a new language with a nice runtime compilation

PHP.reboot a new language with a nice runtime compilation

DinnerAtPiatti

2009-09-26T14:07:16Z

Forax: /* Constant Pool Constants */

Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner.

Emboldened by good food and drink, some of the JSR 292 EG members and others (Forax, Ohrstrom, Szegedi, Bini, Rose, ...) worked on some hard remaining issues. Here are the napkins to prove it.

{|
|[[Image:FridayDinnerNapkin1.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin2.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin3.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin4.jpg|160px|thumb|frameless]]
|}

==== MethodHandle sub-kernel ====

<pre>
class MH {
MT type()
? exactInvoke(?)
? genericInvoke(?)
? varargsInvoke(Object...) // maybe? does a spread

MH convertArguments(MT)
MH bind(x)
MH spreadArguments() // creates a spreader
MH collectArguments(int n) // creates a fixed-arity collector

MH convertArgments(MT)

"MH collectVarargs()" // maybe? creates a variable-arity collector

toString() ??
examine() ??
</pre>

Rename <tt>MH.insertArgument</tt> to <tt>MH.bind</tt> or (per Ola) <tt>MH.prependArgument</tt>.

Perhaps rename <tt>MH.convertArguments</tt> to <tt>MH.asType</tt>.
This is needed as a fundamental factory to create MHs of arbitrary exact types.

==== What should toString return? ====
Simple answers:
* Implementation-dependent
* Object.toString
* Current RI: The simple-name of the target method. (For system-defined combinators, delegates to target.toString; user-defined ones also.) Simple and useful.

==== Completely Generic Argument Collection ====
As Fredrik has blogged, with genericInvoke we allow one method handle to accept any call type, as long as they have a certain given arity. This allows us to glue together method handles without generating signature specific bytecodes.

But it still requires (sometimes) arity-specific bytecodes; there are currently up to 256 different arities in the JVM. This is close enough to the "infinite bytecode" requirement to be impractical.

Possible Solution: Allow a "varargs" method handle type, which can be generically invoked from any call site, of any signature, and (moreover) any arity. It would be uniformly able to collect arguments from any call site.

Example:
<pre>
Object foo(Object[] arglist)
{ ...do something complicated with arglist... }
MH foo = #foo;
foo.genericInvoke(); // WMT, arity
foo.genericInvoke(1); // CCE Integer != Object[]
foo.genericInvoke(1,2); // WMT, arity
MH bar = foo.collectVarargs();
bar.genericInvoke(); // = foo.exactInvoke(new Object[]{})
bar.genericInvoke(1); // = foo.exactInvoke(new Object[]{1})
bar.genericInvoke(1,2); // = foo.exactInvoke(new Object[]{1,2})
</pre>

The <tt>MH.type</tt> of such a MH would be some special value that would make it impossible to perform exact invocation.

Spreading and collecting are of course interrelated:
{| border="1"
! !! spreading from av to mh(x,y) !! collecting from (x,y) to mh(av)
|-
| call || mh.varargsInvoke(av) || mh.exactInvoke(new Object[]{x,y})
|-
| adapt || mh.spreadArgumments() || mh.collectArguments(2)
|}

Note that <tt>collectArguments</tt> could be implemented by <tt>collectVarargs</tt> plus <tt>asType</tt>.

==== Calling Sequences ====

MH.genericInvoke does autoboxing. Can result in an OOM error. The JVM can make the adapter non-blocking, by preallocating all the boxing memory in advance (in thread-local buffer) before advancing into the call. If the allocation fails, the call site is restarted after GC.

<pre>// virtual call through vtable:
mov [obj] -> ecx
call [ecx+off]
</pre>

<pre>// mh call through vtable:
mov [obj] -> ecx
mov [obj+6] -> edx
call [ecx+edx]
</pre>

<pre>// inexact call to DMH
// esi=this, edi/eax/edx=args
cmp [obj+8], #ExactMT
jmp/eq [...generic method entry...]

GenericMethodEntry:
...adjust arguments, etc...
push ebp
call [...exact method entry...]
... adjust return value...
pop ebp
ret
</pre>

The adapter stub can be generated once per method. Better to generate one per signature; need linkage register:
<pre>// generic method entry adapter, per-signature version
alias dest = r8 // linkage
mov dest <- #(...exact method entry...)
if (cs.type == mh.type)
call [dest]
else
call [dest-8] // pushes call to r8
</pre>

Note the need for special stack frames for adapting the return value.

==== Java Method Handles ====

<pre>
class Foo extends JavaMethodHandle {
Foo() { super(#myInvoke); }
void myInvoke() { ... }
}
</pre>

==== Constant Pool Constants ====
Should be for MethodType and four kinds of MH: virtual/interface, static, special.

Idea: Have the constant pool format for CONSTANT_MethodHandle_info be parameterized by (a) a member reference, and (b) a bytecode point (invokespecial, etc.). Makes clear the correspondence between the symbolic reference and the semantics of the resulting method handle. This also extends naturally to all other symbolic references:
* invokevirtual, CONSTANT_Methodref = findVirtual (must be class)
* invokeinterface, CONSTANT_InterfaceMethodref = findVirtual (must be interface)
* invokestatic, CONSTANT_Methodref = findStatic
* invokespecial, CONSTANT_Methodref = findSpecial
* getfield, CONSTANT_Fieldref = unreflectGetter (must be non-static)
* getstatic, CONSTANT_Fieldref = unreflectGetter (must be static)
* putfield, CONSTANT_Fieldref = unreflectSetter (must be non-static)
* putstatic, CONSTANT_Fieldref = unreflectSetter (must be static)

CONSTANT_MethodHandle_info tag can be 15.

For MethodType, I (Rémi) propose to add a new constant pool format CONSTANT_MethodType_info
CONSTANT_MethodType_info {
u1 tag;
u2 method_descriptor_index;
}

tag
The tag item of the CONSTANT_MethodType_info structure has the value CONSTANT_MethodType (14).
method_descriptor_index
The value of the descriptor_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info (§4.4.7) structure representing a valid method descriptor (§4.3.3).

Also LDC instruction spec should be changed to allow CONSTANT_MethodHandle_info and CONSTANT_MethodType_info.
About the runtime semantics,
LDC CONSTANT_MethodType_info == LDC CONSTANT_MethodType_info is required to return true
if the constant values are equals.
The same is not true with LDC CONSTANT_MethodHandle_info.

Advantages to using constant pool:
* static checking, static analysis tools
* pre-linking, application-level early binding
* less need for user-managed cache variables (static final private MethodHandle FOO = ...)

==== Exactly Typed Guards ====
(napkins #3, #4)

Attila's MOP handles overload resolution. This makes it unable to use plain invokevirtual calls (MHs.findVirtual) even as an optimization. Reason: A virtual method may be overlapped by another method which "steals" some of its argument types. This could happen even with an "innocent looking" method like Object.equals. For example, <tt>String.equals(String)</tt> steals string arguments from <tt>String.equals(Object)</tt>, when overloading is resolved. It usually cannot be proved that this won't happen; see example below where <tt>Baz</tt> calls <tt>Bar</tt>, and later on <tt>Foo</tt> is loaded to complicate the resolution of <tt>Bar.f</tt>.

As a result, type guards for overloaded methods must use equality comparisons on classes, not the more "natural" instanceof.

<pre>
class Bar {
int f(Object o) { ... }
// f might also be Bar.equals inherited from Object
}
class Baz extends Bar {
{ invokedynamic f(String) ->
guardWithTest({=> o.getClass == Bar.class}, Bar.#f, ...)
}
}
// later loaded:
class Foo extends Bar {
int f(String s) { ... }
}
</pre>

Open Problem: Is there a way to register interest in class hierarchy changes, in such a way that the MOP could use virtual invocations, and "devirtualize" (like JVMs do) if a conflicting overloading is ever loaded? The difficulty is defining a critical section during which (a) a new class is installed in the hierarchy, and (b) dependent call sites are reset, while (c) no calls are in progress. It's the same critical section that JVMs (like Hotspot) use at a low level. It should not allow execution of bytecodes. It could, perhaps, associated invokedynamic sites with some given point in the type hierarchy, such that those points would be invalidated when new classes are loaded under that point.

The problem gets a little more complex if argument or return types are replaced arbitrarily; for example <tt>int Foo.equals(boolean)</tt> overriding <tt>boolean Object.equals(Object)</tt>.

==== Invalidation ====
Dynamic languages can reverse themselves: The meaning of a call site can change over time due to changes in the runtime, especially in the application's type schema.

Groovy currently gets a serious performance hit from polling a schema evolution counter on each method call. This counter is volatile, to make sure it updates to every thread. This is a typical "pull" or "polling" type of invalidation logic.

JSR 292 will include "push" invalidation.

Call site states, excluding invalidation:
* not yet executed
* executed, but bootstrap method not yet returned
* linked: reified as a unique call site (returned from BSM)
* relinked: <tt>CallSite.setTarget</tt> can be called any number of times

Note that <tt>CS.setTarget</tt> does not have volatile semantics. Threads may take any amount of time to witness changes. This is by design.

Key question: How do we (a) back up to a known state, (b) forcing all threads to see the change, (c) without race conditions, and (d) without per-call polling? Answer: Collect call sites for invalidation, and bulk-invalidate at a well-defined safepoint.

(Why bulk? Because most implementations will be too slow for piecemeal work; need big transactions.)

The JVM (at least, Hotspot) has subtle mechanisms for this, to perform revirtualization when a devirtualized call site becomes invalid, due to class loading (class schema change). After some discussion, it was agreed that GCs in general require such global critical sections too.

The answer we came up with is "full back-out at a safepoint". Details:
* The runtime (language or application) initiates any global transaction it wants
* The runtime marks the CallSite it wants to invalidated (and any other sites as well)
* The runtime requests bulk invalidation from the JVM
* The JVM invalidates the CallSite in a global critical section ("safepoint")
* During this safepoint, every affected invokedynamic instruction is either blocked or has rolled forward
* The CallSite object is discarded (collectable by GC)
* The invokedynamic instruction is backed up to a "not yet executed" state
* As soon as the JVM returns, threads may execute the invokedynamic instruction, triggering its BSM
* The BSM interacts correctly with the runtime's current transaction

Backing all the way out to an unlinked state is cleanest. Alternative: Back up to a "known initial target value" on the call site. Seems to require messy bytecode execution in uncontrolled contexts, to compute and store the initial target value.

Implications of full back-out:
* BSM can return the same call site as last time, if desired (''only if'' we supply an "is-live" query)
* gives a "hook" for changing the class and/or identity of a call site
* 1-to-many bytecode-to-CS relation meshes nicely with call site splitting (which Remy has rightly insisted on)

This design allows threads to run invokedynamic instructions with complete concurrency except during specified global safepoints.

Remaining problem: Define what it means to "roll forward" through an invokedynamic call. Should execute the whole call site target entry including pre-entry adapters, including argument boxing, etc. Can define this w.r.t. the functions in MHs, but this adds a funny privilege to them. This could interact with tail-call guarantees.

DinnerAtPiatti

2009-09-26T14:03:11Z

Forax:

Friday night after the Summit, some of us who hadn't had enough yet went across the street to Piatti for dinner.

Emboldened by good food and drink, some of the JSR 292 EG members and others (Forax, Ohrstrom, Szegedi, Bini, Rose, ...) worked on some hard remaining issues. Here are the napkins to prove it.

{|
|[[Image:FridayDinnerNapkin1.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin2.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin3.jpg|160px|thumb|frameless]]
|[[Image:FridayDinnerNapkin4.jpg|160px|thumb|frameless]]
|}

==== MethodHandle sub-kernel ====

<pre>
class MH {
MT type()
? exactInvoke(?)
? genericInvoke(?)
? varargsInvoke(Object...) // maybe? does a spread

MH convertArguments(MT)
MH bind(x)
MH spreadArguments() // creates a spreader
MH collectArguments(int n) // creates a fixed-arity collector

MH convertArgments(MT)

"MH collectVarargs()" // maybe? creates a variable-arity collector

toString() ??
examine() ??
</pre>

Rename <tt>MH.insertArgument</tt> to <tt>MH.bind</tt> or (per Ola) <tt>MH.prependArgument</tt>.

Perhaps rename <tt>MH.convertArguments</tt> to <tt>MH.asType</tt>.
This is needed as a fundamental factory to create MHs of arbitrary exact types.

==== What should toString return? ====
Simple answers:
* Implementation-dependent
* Object.toString
* Current RI: The simple-name of the target method. (For system-defined combinators, delegates to target.toString; user-defined ones also.) Simple and useful.

==== Completely Generic Argument Collection ====
As Fredrik has blogged, with genericInvoke we allow one method handle to accept any call type, as long as they have a certain given arity. This allows us to glue together method handles without generating signature specific bytecodes.

But it still requires (sometimes) arity-specific bytecodes; there are currently up to 256 different arities in the JVM. This is close enough to the "infinite bytecode" requirement to be impractical.

Possible Solution: Allow a "varargs" method handle type, which can be generically invoked from any call site, of any signature, and (moreover) any arity. It would be uniformly able to collect arguments from any call site.

Example:
<pre>
Object foo(Object[] arglist)
{ ...do something complicated with arglist... }
MH foo = #foo;
foo.genericInvoke(); // WMT, arity
foo.genericInvoke(1); // CCE Integer != Object[]
foo.genericInvoke(1,2); // WMT, arity
MH bar = foo.collectVarargs();
bar.genericInvoke(); // = foo.exactInvoke(new Object[]{})
bar.genericInvoke(1); // = foo.exactInvoke(new Object[]{1})
bar.genericInvoke(1,2); // = foo.exactInvoke(new Object[]{1,2})
</pre>

The <tt>MH.type</tt> of such a MH would be some special value that would make it impossible to perform exact invocation.

Spreading and collecting are of course interrelated:
{| border="1"
! !! spreading from av to mh(x,y) !! collecting from (x,y) to mh(av)
|-
| call || mh.varargsInvoke(av) || mh.exactInvoke(new Object[]{x,y})
|-
| adapt || mh.spreadArgumments() || mh.collectArguments(2)
|}

Note that <tt>collectArguments</tt> could be implemented by <tt>collectVarargs</tt> plus <tt>asType</tt>.

==== Calling Sequences ====

MH.genericInvoke does autoboxing. Can result in an OOM error. The JVM can make the adapter non-blocking, by preallocating all the boxing memory in advance (in thread-local buffer) before advancing into the call. If the allocation fails, the call site is restarted after GC.

<pre>// virtual call through vtable:
mov [obj] -> ecx
call [ecx+off]
</pre>

<pre>// mh call through vtable:
mov [obj] -> ecx
mov [obj+6] -> edx
call [ecx+edx]
</pre>

<pre>// inexact call to DMH
// esi=this, edi/eax/edx=args
cmp [obj+8], #ExactMT
jmp/eq [...generic method entry...]

GenericMethodEntry:
...adjust arguments, etc...
push ebp
call [...exact method entry...]
... adjust return value...
pop ebp
ret
</pre>

The adapter stub can be generated once per method. Better to generate one per signature; need linkage register:
<pre>// generic method entry adapter, per-signature version
alias dest = r8 // linkage
mov dest <- #(...exact method entry...)
if (cs.type == mh.type)
call [dest]
else
call [dest-8] // pushes call to r8
</pre>

Note the need for special stack frames for adapting the return value.

==== Java Method Handles ====

<pre>
class Foo extends JavaMethodHandle {
Foo() { super(#myInvoke); }
void myInvoke() { ... }
}
</pre>

==== Constant Pool Constants ====
Should be for MethodType and four kinds of MH: virtual/interface, static, special.

Idea: Have the constant pool format for CONSTANT_MethodHandle_info be parameterized by (a) a member reference, and (b) a bytecode point (invokespecial, etc.). Makes clear the correspondence between the symbolic reference and the semantics of the resulting method handle. This also extends naturally to all other symbolic references:
* invokevirtual, CONSTANT_Methodref = findVirtual (must be class)
* invokeinterface, CONSTANT_InterfaceMethodref = findVirtual (must be interface)
* invokestatic, CONSTANT_Methodref = findStatic
* invokespecial, CONSTANT_Methodref = findSpecial
* getfield, CONSTANT_Fieldref = unreflectGetter (must be non-static)
* getstatic, CONSTANT_Fieldref = unreflectGetter (must be static)
* putfield, CONSTANT_Fieldref = unreflectSetter (must be non-static)
* putstatic, CONSTANT_Fieldref = unreflectSetter (must be static)

CONSTANT_MethodHandle_info tag can be 15.

For MethodType, I (Rémi) propose to add a new constant pool format CONSTANT_MethodType_info
CONSTANT_MethodType_info {
u1 tag;
u2 method_descriptor_index;
}

tag
The tag item of the CONSTANT_MethodType_info structure has the value CONSTANT_MethodType (14).
method_descriptor_index
The value of the descriptor_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info (§4.4.7) structure representing a valid method descriptor (§4.3.3).

Also LDC instruction spec should be changed to allow CONSTANT_MethodHandle_info and CONSTANT_MethodType_info.

Advantages to using constant pool:
* static checking, static analysis tools
* pre-linking, application-level early binding
* less need for user-managed cache variables (static final private MethodHandle FOO = ...)

==== Exactly Typed Guards ====
(napkins #3, #4)

Attila's MOP handles overload resolution. This makes it unable to use plain invokevirtual calls (MHs.findVirtual) even as an optimization. Reason: A virtual method may be overlapped by another method which "steals" some of its argument types. This could happen even with an "innocent looking" method like Object.equals. For example, <tt>String.equals(String)</tt> steals string arguments from <tt>String.equals(Object)</tt>, when overloading is resolved. It usually cannot be proved that this won't happen; see example below where <tt>Baz</tt> calls <tt>Bar</tt>, and later on <tt>Foo</tt> is loaded to complicate the resolution of <tt>Bar.f</tt>.

As a result, type guards for overloaded methods must use equality comparisons on classes, not the more "natural" instanceof.

<pre>
class Bar {
int f(Object o) { ... }
// f might also be Bar.equals inherited from Object
}
class Baz extends Bar {
{ invokedynamic f(String) ->
guardWithTest({=> o.getClass == Bar.class}, Bar.#f, ...)
}
}
// later loaded:
class Foo extends Bar {
int f(String s) { ... }
}
</pre>

Open Problem: Is there a way to register interest in class hierarchy changes, in such a way that the MOP could use virtual invocations, and "devirtualize" (like JVMs do) if a conflicting overloading is ever loaded? The difficulty is defining a critical section during which (a) a new class is installed in the hierarchy, and (b) dependent call sites are reset, while (c) no calls are in progress. It's the same critical section that JVMs (like Hotspot) use at a low level. It should not allow execution of bytecodes. It could, perhaps, associated invokedynamic sites with some given point in the type hierarchy, such that those points would be invalidated when new classes are loaded under that point.

The problem gets a little more complex if argument or return types are replaced arbitrarily; for example <tt>int Foo.equals(boolean)</tt> overriding <tt>boolean Object.equals(Object)</tt>.

==== Invalidation ====
Dynamic languages can reverse themselves: The meaning of a call site can change over time due to changes in the runtime, especially in the application's type schema.

Groovy currently gets a serious performance hit from polling a schema evolution counter on each method call. This counter is volatile, to make sure it updates to every thread. This is a typical "pull" or "polling" type of invalidation logic.

JSR 292 will include "push" invalidation.

Call site states, excluding invalidation:
* not yet executed
* executed, but bootstrap method not yet returned
* linked: reified as a unique call site (returned from BSM)
* relinked: <tt>CallSite.setTarget</tt> can be called any number of times

Note that <tt>CS.setTarget</tt> does not have volatile semantics. Threads may take any amount of time to witness changes. This is by design.

Key question: How do we (a) back up to a known state, (b) forcing all threads to see the change, (c) without race conditions, and (d) without per-call polling? Answer: Collect call sites for invalidation, and bulk-invalidate at a well-defined safepoint.

(Why bulk? Because most implementations will be too slow for piecemeal work; need big transactions.)

The JVM (at least, Hotspot) has subtle mechanisms for this, to perform revirtualization when a devirtualized call site becomes invalid, due to class loading (class schema change). After some discussion, it was agreed that GCs in general require such global critical sections too.

The answer we came up with is "full back-out at a safepoint". Details:
* The runtime (language or application) initiates any global transaction it wants
* The runtime marks the CallSite it wants to invalidated (and any other sites as well)
* The runtime requests bulk invalidation from the JVM
* The JVM invalidates the CallSite in a global critical section ("safepoint")
* During this safepoint, every affected invokedynamic instruction is either blocked or has rolled forward
* The CallSite object is discarded (collectable by GC)
* The invokedynamic instruction is backed up to a "not yet executed" state
* As soon as the JVM returns, threads may execute the invokedynamic instruction, triggering its BSM
* The BSM interacts correctly with the runtime's current transaction

Backing all the way out to an unlinked state is cleanest. Alternative: Back up to a "known initial target value" on the call site. Seems to require messy bytecode execution in uncontrolled contexts, to compute and store the initial target value.

Implications of full back-out:
* BSM can return the same call site as last time, if desired (''only if'' we supply an "is-live" query)
* gives a "hook" for changing the class and/or identity of a call site
* 1-to-many bytecode-to-CS relation meshes nicely with call site splitting (which Remy has rightly insisted on)

This design allows threads to run invokedynamic instructions with complete concurrency except during specified global safepoints.

Remaining problem: Define what it means to "roll forward" through an invokedynamic call. Should execute the whole call site target entry including pre-entry adapters, including argument boxing, etc. Can define this w.r.t. the functions in MHs, but this adds a funny privilege to them. This could interact with tail-call guarantees.

JSR292Backport

2008-09-25T23:50:59Z

Forax: /* Abstract */

== invokedynamic backport + VM,anonymous classes ==
Rémi Forax

; Project: http://code.google.com/p/jvm-language-runtime/

In order to fasten adoption of JSR292, this is a project to provide a backport of JSR292 that will work, with Java 5 or Java 6.

=== Abstract ===
; Talk Abstract: invokedynamic-backport: - why, how-to - at runtime/at compile time, weaver/agent - features/missing features/ roadmap - JSR292 API vs backport API - invokedynamic - method handles/guards/adapter handle - linkage/call sites invalidation Proposed API for anonymous classes in the VM: - Uses cases - Proposed API - Using patched classes - implementing Java inner class with VM anonymous class

This presentation first presents the API allowing to create anonymous class in the VM and do some constant pool patching.
Then I will show some the corner cases of the current JSR292 in regards to the backport

http://wiki.jvmlangsummit.com/pdf/JSR292Backport

; Speaker Notes: Two light talks (30min+10min) about the invokedynamic backport: a JSR 292 implementation compatible with jdk 1.5 available at http://code.google.com/p/jvm-language-runtime/ and a proposed Java side API to VM anonymouses class.

=== Author Bio ===
* <insert bio here>

=== Key Issues for Discussion (cooperative) ===
''(please expand cooperatively)''
[[Talk:InvokeDynamic]]

== PDF ==
[[Image:Jsr292-backport.pdf]]

JSR292Backport

2008-09-25T16:19:30Z

Forax: /* Abstract */

== Abstract ==
In order to fasten adoption of JSR292,
a project is to provide a backport of JSR292 that
will work, with Java 5 or Java 6.

This presentation first presents
the API allowing to create anonymous class in the VM
and do some constant pool patching.
Then i will show some the corner cases of the
current JSR292 in regards to the backport

== PDF ==
[[Image:Jsr292-backport.pdf]]

JSR292Backport

2008-09-25T16:19:03Z

Forax: JSR292 backport

File:Jsr292-backport.pdf

2008-09-25T16:09:15Z

Forax: jsr 292 backport presentation

jsr 292 backport presentation