On 06/16/2011 08:23 PM, Charles Oliver Nutter wrote: > On Wed, Jun 15, 2011 at 4:58 PM, Rémi Forax<fo...@univ-mlv.fr> wrote: >> On 06/15/2011 09:55 PM, Charles Oliver Nutter wrote: >>> On Wed, Jun 15, 2011 at 2:42 PM, Rémi Forax<fo...@univ-mlv.fr> wrote: >>>> You can use invokeWithArguments instead of invokeExact. >>> Yes, that helps, but I was under the impression that invokeExact would >>> do a better job inlining at least the early phases of the invocation >>> into the call site. That may ore may not matter for my inline-caching >>> paths, though, which are the only places I do direct MH invocation. >> These method handle calls are not inlined >> because they are used in the slow path which is not hot (or should not >> be hot) >> and they are not constant. >> >> So these invokeExact are plain old function call. >> invokeExact is faster than invokeWithArguments >> which requires to create an array and to cast all arguments to match >> the method type of the callee. So here you lost a bit of efficiency. > That's what I figured. A small perf hit but it would compile ok on > Java 6. That's probably a reasonable trade-off.
The other reasonable solution is to patch the jdk6 compiler to raise an error if MH.invoke*() is used. >> BTW, you should store the target and the guard in two local variables >> to avoid to go through the guard again when invoking the target. >> If someone mutate a class in a loop, I will run out of the stack >> because the fallback will be called recursively. > Yes, you're right. It would only happen in the rare case that > someone's constantly mutating the class and the fallback can't > complete successfully before a mutation happens. In other words, if > someone were writing bad/broken code to begin with. But I had intended > to save the target off, and accidentally reassigned it rather than > setting it into the site immediately. Good catch, thanks. > > - Charlie Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev