Charles Oliver Nutter
headius at headius.com
Thu Jun 16 11:23:41 PDT 2011
On Wed, Jun 15, 2011 at 4:58 PM, Rémi Forax <forax at 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<forax at 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.
> 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.
More information about the mlvm-dev