Indy crash

[Rémi Forax]

On 06/16/2011 08:23 PM, Charles Oliver Nutter wrote:
> 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.

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