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?
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.
- Charlie
--
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.
