On 11/01/2013 14:16, "Eric Bodden" <eric.bod...@ec-spride.de> wrote:
>Thanks Duncan, for the fast response. > >To clarify, when you say... >> The call site created by a bootstrap method will normally >> change its own target during execution into a a guardWithTest chain >>which >> would dispatch to several targets, and when it gets too big for that may >> start fetching and directly invoking other method handles or passing >>them >> back to an exact invoker. >... do you mean that this is implemented with in the java.lang.invoke >API or do you mean that client implementations using that API will >normally generate such a guardWithTest chain? Yes. :-) MutableCallSites (which are specified in the java.lang.invoke APIs) support setTarget() to set the callsite's target, and there are a set of methods on java.lang.invoke.MethodHandles for combining method handles in various ways. I would expect almost all language implementations using method handles would make quite heavy use of those APIs, and most will bootstrap to a call site with some sort of fallback target and change that target on the first invocation to a guardWithTest. >> I think your only real option is intercept the calls that get the method >> handles in the first place, so you'd need to transform most calls to >> Lookup objects and unreflect(). That shouldn't be too hard a bit of code >> transformation to do. > >That's a good idea which we can try. Unfortunately it will require >modifications to the JDK. That's something I was trying to avoid. Could you not do this by transforming the code outside the JDK that calls those methods? I assume you have to do something similar to existing code which uses reflection to avoid it bypassing your advice-execution code. Oh, and I've just realised you'll also have to do something about any MethodHandles that have been compiled into a classes constant pool as well. Some of those will be the bootstrap methods for invokeDynamic instructions, but other things could have been stuffed in their. Regards, Duncan. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
