On 01/26/2011 09:43 AM, Jochen Theodorou wrote:
Hi all,
since I am experimenting a bit with MethodHandles and invokedynamic
these days on java7b125 I stumbled on some things...
(1) How does the signature of the bootstrap method has too look like?
So far I found (Class,String,MethodType):CallSite and
(Lookup,String,MethodType):CallSite, that both work.
A bit of history, jdk7b125 has two ways to encode an invokedynamic, the
two ways use the same opcode
but referenced item in the constant pool is constant 17 or constant 18.
constant 17 is the old encoding that use java.dyn.Linkage to find the
bootstrap method and this bootstrap method
has no support for bootstrap arguments.
So for constant 17 the corresponding BSM is
(Class,String,MethodType):CallSite.
ASM 3.2/3.3 supports only this encoding.
This support is now deprecated and will be removed soon, current beta
build is ok with constant 17 and constant 18.
constant 18 is the new encoding. In that case the bootstrap method +
bootstrap arguments must be given
for each invokedynamic.
The BSM is (Lookup,String,MethodType, *ARGS*):CallSite where ARGS can be
positional arguments or varargs arguments
By example if my invokedynamic encodes two boostraps arguments: 3 and "foo",
positional BSM: (Lookup,String,MethodType,int,String):CallSite
varargs BSM: (Lookup,String,MethodType,Object...):CallSite
In fact, this signature also works:
varargs BSM: (Lookup,String,MethodType,int, Object...):CallSite
the varargs way has the Java calling semantics.
The BSM calling semantics is fully described here:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/lang/invoke/package-summary.html
ASM 4.0 (not released yet) only supports the new encoding.
And to make things a little more complex, positional/varargs semantics
is not yet fully supported by jdk7b126.
It uses an older mecanism discribed here:
http://download.java.net/jdk7/docs/api/java/dyn/package-summary.html
Basically, if you have zero or one BSM argument, the BSM will be called
with positional arguments,
if you have more than one BSM arguments, the BSM will be called with the
varargs semantics.
But what I could not get working was a version that takes an Object[]
for the presented arguments. Simply attaching an Object[] or Object...
taking parameter in the signature above did not work. When looking at
Remi's named argument example in
http://weblogs.java.net/blog/forax/archive/2011/01/21/jsr-292-goodness-named-parameters
then I see a bootstrap method that is not usable for me in java7b125.
I use constant 18 and you use constant 17 :)
(2) Since Linkage#registerBootstrapMethod should not be used anymore I
am currently not fully sure as of how to replace it. The documentation
says something but an annotation, which I cannot use, since I generate
the class myself... it talks about marking the method... ok.. but how
actually? From a users perspective I find there a lot of information
that does help me. A simple example would be so much better. Is anyone
able to give me one that then works for b125?
get ASM4-beta2 from my blog post:
http://weblogs.java.net/blog/forax/archive/2011/01/21/jsr-292-goodness-named-parameters
and encode invokedynamic with it, it will work.
BTW, ASM4 is still in beta because I wait the rename from java.dyn to
java.lang.invoke.
(3) MH#invokeExact as well as MH#invokeGeneric do cause trouble to me
in java7b125. Maybe it is because the program that uses the handles is
the eclipse compiler, but I was not aware that for these we have
compiler magic on work. Anyway, what I get is the handle complaining
about the Object[] produced to store the arguments of the invokeExact
and invokeGeneric. The only version I could get to work in that setup
is MH#withArguments. is that supposed to be like this?
Eclipse doesn't recognize MH#invokeExact and Mh#invokeGeneric as magic
so it encodes them by boxing arguments
in an array instead of calling them with a polymorphic signature.
We have to wait the support of JSR 292 in Eclipse before being able to
use it.
Thanks for the help
bye Jochen
cheers,
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
