On 11/24/2011 12:45 PM, Jochen Theodorou wrote:
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.
Yes, because of the bootstrap method, you interpose a stack frame loaded
with the classloader of RT, so you will have trouble with all calls that
are sensitive to
the class of the method in the stack trace.
The workaround I use is to put the jar containing RT in the bootstrap
classloader.
It's far from ideal.
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?
the guard can produce additional stack frames, the guard method is
itself loaded from a class
of the bootclasspath but this method can calls methods in RT.
Practically, problems come when you bootstrap or when the slow path is
called because
both call methods in RT.
(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...
yes.
bye blackdrag
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.
