[[Invoke]] and implicit method calls
till at tillschneidereit.net
Wed Sep 18 13:37:22 PDT 2013
(sending from the right address this time, with apologies for the double
post to the CC'd people.)
On Wed, Sep 18, 2013 at 6:56 PM, Brendan Eich <brendan at mozilla.com> wrote:
> David Bruant <mailto:bruant.d at gmail.com>
>> September 18, 2013 12:52 PM
>> Why? (damned! how do I find myself defending invoke while I'm relatively
>> against it...)
>> Till Schneidereit's enthusiasm about it and the promised boost for
>> Shumway suggests that the performance difference is significant to not be a
I'm not entirely sure my feelings about an invoke trap are accurately
described by the word "enthusiastic". ;)
Shumway means AS3 => JS and AS3 indeed had an invoke trap (from ES4
> Actual measurements with analysis of state of implementation could be
>> relevant here.
>> cc'ing Till in hope he's done such measurements.
> Right, it's a bit rash to say performance counts for nothing. It is
> usually secondary, though -- and rightly so. Optimizations come along over
> time. Asymptotic complexity is a fair concern, and allocations cost -- but
> if a JS JIT can prove they won't be observed then it can eliminate them.
I haven't done any measurements, no. My interest in an invoke trap is
mainly driven by Shumway's requirements. The fact that AS3 proxies have an
invoke trap means that, as soon as any proxies are used in a vm instance at
all, we have to guard all method calls in our JITted code at callsites
where we can't prove that the receiver won't ever be a proxy. This affects
a large percentage of Flash applications, because remoting (Flash's RPC
solution) uses proxies to forward method calls on the client-side object to
the server side as RPCs.
Note that I don't think that "AS3 has invoke trapping and Shumway's having
a hard time without JS having it, too" is a good argument, and I'm not
making it. If the invoke trap is seen as superfluous or even detrimental,
JS shouldn't get it.
Frankly, I can't come up with very good non-Shumway-related arguments in
favor of an invoke trap. It *seems* to me like being able to differentiate
between method calls and property gets on the object protocol level makes
forwarding of calls where your forwarding target doesn't give you the info
needed to identify calls before the fact. Meaning remote procedure calls.
Why you'd need to support both non-callable properties and methods on an
RPC client, I don't know, however.
The fact remains that, without the invoke trap, proxy users have to get the
information whether a method call is about to happen from other sources,
even though the runtime would be perfectly able to provide it. Putting the
call-if-defined wrinkle caused (or exposed) by other spec algorithms aside
for a minute, I'd argue that not providing this information makes using
proxies strictly more complex, and strictly less performant.
Taking that wrinkle into consideration again, I still think it might be
handled by wrapping the "get function, call if get succeeded" steps used in
some spec algorithms into an abstract operation. That operation could have
a special case along the lines of "if the receiver is a proxy with an
invoke trap, call that with the args list". That would mean that having an
invoke trap causes all of these maybe-calls to be actual calls. Which seems
ok to me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss