Am 29.11.2011 10:53, schrieb Charles Oliver Nutter:
On Mon, Nov 28, 2011 at 10:20 AM, Jochen Theodorou<blackd...@gmx.org> wrote:
if the guards produce stackframes visible to Class.forName, then putting the
bootstrap method on each class, won't do it...I guess it won't do it anyway,
since I need the first time to invoke the method handle myself and then Java
API will be in the way. The funny thing is... with Groovy's current method
call site caching it works most of the time... well, I have to think about
it a bit more. But if I have to generate classes again the gain from
invokedynamic is not that much
Except the gain of having invokedynamic actually optimize dynamic
calls as well as virtual calls. But perhaps that's not much to you?
that is then a tradeoff between performance and correctness.
Ideally, your stack should only end up having JDK classes leading up
to the eventual bound target method (such as Class.forName). Here's a
sample trace out of JRuby:
system ~/projects/jruby $ jruby -Xbacktrace.style=raw -rjava -e
"java.lang.Thread.dumpStack"
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1342)
at
java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L0(MethodHandleImpl.java:790)
at
java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
at
org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:133)
at ruby.__dash_e__.__file__(-e:1)
at ruby.__dash_e__.load(-e)
at org.jruby.Ruby.runScript(Ruby.java:732)
at org.jruby.Ruby.runScript(Ruby.java:725)
at org.jruby.Ruby.runNormally(Ruby.java:632)
at org.jruby.Ruby.runFromMain(Ruby.java:481)
at org.jruby.Main.doRunFromMain(Main.java:343)
at org.jruby.Main.internalRun(Main.java:255)
at org.jruby.Main.run(Main.java:221)
at org.jruby.Main.run(Main.java:205)
at org.jruby.Main.main(Main.java:185)
The dumpStack call has in front of it two java.lang.invoke methods and
then the "fallback" installed by the JRuby bootstrap method. In your
case, this would be the first non-bootclasspath method on the stack.
The key detail for this to work (and for the best invokedynamic
optimizations to work) is that your straight-through invocation path
should be all handle invocations. If there's non-java.lang.invoke
frames in that sequence, you're likely defeating invokedynamic
optimization and potentially throwing off stack-based calculations
like classloader and security policy.
I see... well that is for later..
for now I have to find out how to add a value to a method call. I
thought insertArguments would do that, but I think that is not right.
Too bad this one has no example.
bye Jochen
--
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 jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
