Is it very different from the call sites in JRuby? They have a solid invokedynamic implementation to look at already. Might inspire you in a few places :-)
Cheers Le 28 nov. 2011 à 17:20, Jochen Theodorou <blackd...@gmx.org> a écrit : > Am 28.11.2011 14:21, schrieb Rémi Forax: > [...] >> 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. > > maybe I will have to make a bootstrap method per class then... but... > >>> 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. > > 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 > > 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 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. > -- 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.
