Am 20.01.2011 18:04, schrieb Rémi Forax:
On 01/20/2011 05:49 PM, Jochen Theodorou wrote:
Hi all,
looks like some stupid fact left my center of attention for quite a
while, so I am asking here to see if I am right or not.
Assuming I have in pseudo code something like this:
Object o1 = foo1()
Object o2 = foo2()
invokeDynamic ("bar", this, o1, o2)
in fact, invokedynamic "bar" (this, o1, o2)
"bar" is constant so it's a boostrap argument not an argument that will
be send each time there is a call.
ah, yes, true
meaning I want to do an dynamic method invocation using o1 and o2 as
arguments to some method on this, which is called bar....
Do I see it right, that the MethodType that will get presented to my
bootstrap method and the call site will have Object for o1 and o2?
the descriptor will be typeOf(this), typeOf(o1), typeOf(o2) + return type
ehm.. so a yes or no? Does typeOf return the runtime type, or the the
type on the java thinks this stack value has on the operand stack? If I
do an ALOAD to get the value from a local variable, then it is most
likely Object, or not?
Actually the typing on the operand stack is still a mystery to me.
And am I right in assuming, that if the runtime type for ox changes,
that this will not invalidate my callsite and that I will have to
guard this if I want that?
yes, you have to guard it. Unlike the DLR, invokedynamic doesn't do
anything by default.
Note that you can install a guard that checks the class of the first
parameter instead of testing its identity.
I have not only to test the first parameter, but all of them. That does
not prevent me from doing a guard of course, but makes me wonder about
the resulting performance.
bye blackrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org
--
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.
