in the blue yonder: thinking about syntax support for invokedynamic

[Rémi Forax]

  Hi all,
John, I really like the first part of the proposal even if I think that 
the syntax can be tweaked a little bit :)
I don't see a need for the second part (bootstrap abstraction).

Testing a VM implementation without having a way to encode easily 
invokedynamic
is really silly and I hope that this syntax will be included in the 
first beta JDK8
as a part of coin (the flip side), JSR 335 or JSR 292 step 2.

I've put Brian and Joe in the loop in order to decide where to put it.

Rémi

Le 03/03/2011 03:55, John Rose a écrit :
> Introduction
>
> The invokedynamic instruction is not designed for use from Java.  And 
> yet there are use cases for syntax support.  Java is (among other 
> things) the primary systems programming language for the JVM.  If you 
> are programming a dynamic language system, you are probably coding a 
> lot of Java.  (There could be rare exceptions, of self-hosting 
> languages which boot from bytecodes.)  If you are using JSR 292, your 
> Java code probably works with method handles and invokedynamic.  In 
> fact, you probably want to code an occasional invokedynamic 
> instruction directly by hand, and find yourself resorting to 
> alternatives like ASM or indify.
>
> A year ago the 292 prototype included basic syntax support, but we 
> yanked it for various reasons.  This note is my attempt to reserve a 
> few neurons for thinking about what syntax support might look like in 
> some future release.
>
> The old support from last year cannot be restored, if only because the 
> essential shape of an invokedynamic instruction has changed.  The new 
> shape strongly affects any design for syntax support.
>
> An invokedynamic call site has a reference to a CONSTANT_InvokeDynamic 
> CP entry (tag 18).  This entry includes:
>  1. name: a non-interpreted Utf8 string
>  2. signature: a type descriptor (inferred from or corresponding to 
> actual arguments and return value)
>  3. bsm: a bootstrap method (expressed as a CONSTANT_MethodHandle)
>  4. bsmargs: a series of zero or more extra static arguments 
> (arbitrary CP entries)
>
> The first two items are packed, as usual, in a CONSTANT_NameAndType. 
>  The other items are stored in the BootstrapMethods class file 
> attribute.  (Both pairs of items are referred to by index from 
> the CONSTANT_InvokeDynamic CP entry.  This implies that they are 
> shareable, which is an interesting property for some use cases.)
>
>
> Dynamic Call Site Syntax
>
> In order to express all these degrees of freedom in Java syntax 
> support, we would need a syntax approximately like this:
>
> Expression = IndyHead '.' IndyTail
>
> IndyHead = 'invokedynamic' '(' BootstrapMethodEntry ')'
>
> IndyTail = name:Identifier dynargs:MethodArguments
>
> MethodArguments = '(' Expression ... ')'
>
> BootstrapMethodEntry =
>     StaticMethodName bsmargs:[',' BSMConstantExpression]*
>   | 'new' StaticClassName bsmargs:[',' BSMConstantExpression]*
>
> BSMConstantExpression =
>     IntegerLiteral | LongLiteral | FloatLiteral | DoubleLiteral
>   | ClassName '.' 'class'
>   | StringLiteral
>   | MethodHandleLiteral | MethodTypeLiteral
>
> The fixed tokens (a keyword 'invokedynamic', parens, dots, commas, 
> etc.) don't matter as much as variable parts.
>
> Each unique BootstrapMethodEntry corresponds to an element of the 
> BootstrapMethods classfile attribute.
>
> Each distinct IndyTail corresponds to a CONSTANT_NameAndType entry in 
> the constant pool.  (Actually, the return value type needs to be 
> inferred also.  Let's just assume the same rules as for 
> MethodHandle.invokeExact.)
>
> An expression IndyHead.IndyTail would compile to code which pushes 
> dynargs (as with MethodHandle.invokeExact), plus a subsequent 
> invokedynamic instruction with the following structure:
>
>   CONSTANT_InvokeDynamic {
>     CONSTANT_NameAndType {
>       name
>       signature = (derived from dynargs and optional result cast)
>     }
>     BootstrapMethods[N] {
>       bsm = CONSTANT_MethodHandle { ...REF_invokeStatic or 
> REF_newInvokeSpecial... }
>       bsmrgs = { ...constant... }
>     }
>   }
>
> This would give Java programmers a basic ability to code up 
> invokedynamic instructions.  Examples:
>
> String x = (String) invokedynamic(new MyCallSite, 
> File.class).name1(false, 3.14);
> invokedynamic(MyModule.myBSM, "argh", 42).name2("foo");

And I stop here :)

Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110307/6e6f5152/attachment.html