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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
