On Jan 20, 2011, at 9:46 AM, Jochen Theodorou wrote:
> 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
There are two kinds of bootstrap arguments. The first three are fixed, and
include the traditional method name (which is a string you interpret). There
can be zero or more extra arguments, which can be anything drawn from the
constant pool.
Ref from b123:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-old/2010-1216/java/dyn/package-summary.html#bsm
Also (and this is new), the BSM can be a variable-arity Java method or
constructor, in which case some or all of the arguments can be packaged up into
an array. (Object... is implemented at present.)
Ref from bleeding edge:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/package-summary.html#args
(This should be available in 2-3 builds.)
>>> 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?
He means the static type, that the verifier sees and the bytecode generator
chose. It is drawn directly from the CONSTANT_NameAndType descriptor for the
invokedynamic instruction.
> Actually the typing on the operand stack is still a mystery to me.
For calls, it's all based on NameAndType descriptors. The verifier ensures
that what is pushed matches those descriptors, and rejects the bytecode if it
cannot prove correctness.
>>> 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.
At any given call site, the performance will depend on (a) the cleverness of
the guard you write, (b) the degree of inlining and optimization provided by
the JIT, and (c) the effectiveness of inline caching at that call site. This
assumes that (a) uses an inline cache algorithm. Because of the way
invokedynamic is specified, (b) is likely to win, because the JVM can inline
custom inline cache logic. Unlike the DLR, you write the logic. Actually,
this is the sort of logic which should be mostly language-independent and tuned
once. Now that JSR 292 is stabilizing, it is time to invest more in the next
layer upwards. Inline caching goes in this layer. Rémi and Attila have
produced some work in this direction.
-- John
--
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.
