Am 24.11.2011 11:24, schrieb Rémi Forax:
Le 24/11/2011 11:15, Jochen Theodorou a écrit :
Hi all,
I started implementing an invokedynamic port of Groovy, but I have two
"complex" questions early on:
(1) Groovy method selection depends on runtime types. This seems to
mean that I need a two step approach for my methods. On the first step
I let the bootstrap return a method handle, that will do the method
selection. In the second step I will replace the target in the call
site, with the now selected method. The result is that only on the
second invocation the real target method will be called directly and
on the first invocation this will happen through the selector. Is that
right?
Yes, only the second call will use the guard.
I think there is a misunderstanding... I am actually talking about
unguarded method handles, at least none on which guardWithTest has been
called. I haven't implemented that part yet.. but is next.... still I
take that as a yes.
Does this also mean that if my target is for example Class.forName,
that it may use a different class loader on the next invocation?
(first time the one of the class containing my method selector method,
second time the class doing the method call originally)
the guard test if the class doesn't change, so if there is more than one
classloader, it can be a different class so it will use the slow path.
Imagine I have a script X that does this: "Class.forName('Foo')". since
in the first invocation I don't know the runtime types yet, I get into
my method selector code (class RT), which will set the new target
(unguarded) of the call site, but also invoke the handle. So I expect
then Class#forName to use not the loader of X, but the loader of RT. If
now the same code is executed again, then I expect this code to use the
loader of X, since now the target is already set to its final value.
As for the guards... if you now say that the guards produce additional
stack frames, visible to Class.forName, then this puzzles me a bit.. why
is that? Or did I misunderstand you again?
(2) for convenience I currently use MethodHandle#asType a lot... is
that good practice or better to be avoided?
By design you have to use asType a lot because the callsite type and the
method handle type must match.
I could also use filterArguments and explicitCastArguments...
bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.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.
