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 [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.
