To be precise, it shows that no-one is using them in a way that was
affected by the breakage. The jits will still call __noSuchMethod__ in
most cases where no binding exists for a particular property lookup.
However, they have been failing for cases where a binding exists, and
the result of the lookup yields a primitive value. In this case,
__noSuchMethod__ would be called by the interpreter, but that behaviour
is not respected by the jits.
This is behind the suggested "compromise" solution of leaving
__noSuchMethod__ behaviour in the engine, but modifying it such that it
only gets called for missing properties, instead of all
missing-or-primitive-valued properties.
Kannan
On 13-09-10 1:20 PM, Luke Wagner wrote:
Ah, good! IIRC, telling get-prop apart from call-prop was previously the major
issue with the proxy-based approach.
We've been steadily removing non-standard features from SM esp. when there is a
standardized alternative, so I'm in favor of removal. The fact that no one has
complained that our jits (incl. the baseline jit which kicks in early and
compiles most everything everywhere) have broken __noSuchMethod__ for several
releases would indicate that noone is really using __noSuchMethod__. (mxr
shows a few Gecko uses to remove, though.)
----- Original Message -----
In addition to what Kannan said, there's also the point that proxies
recently grew an [[Invoke]] trap, so it's even easier to satisfy
__noSuchMethod__ usecases with proxies. (Or will be, once bug 878605 lands.)
On Tue, Sep 10, 2013 at 5:35 PM, Kannan Vijayan <[email protected]>wrote:
I'd like to dredge up this topic and resolve it once and for all. Please
see bug 912303 for why I'm bringing this up now:
https://bugzilla.mozilla.org/**show_bug.cgi?id=912303<https://bugzilla.mozilla.org/show_bug.cgi?id=912303>
As it stands, our current JITs (neither Ion nor Baseline, nor Jaeger
before that) do not respect __noSuchMethod__ semantics, and the fix for
this bug will be painful and unnecessarily complex and heavyweight.
__noSuchMethod__ hurts us in ways that we can't defend against with the
usual techniques. Let me explain in more detail.
Whenever we attach an optimized stub (either Baseline or Ion) for any
CALLELEM or CALLPROP operation, we MUST check the result to see if it's a
primitive, and MUST jump to a slowpath to make a VM-call to run
|OnUnknownMethod|. This is the _best_ possible solution, and it involves
at the minimum the insertion of a likely-to-fail primitive-value check into
property-access hot paths, and a whole lot of complexity (and bloat) to
every IC stub that does property accesses.
"But wait!" you say, "why don't we just not attach stubs when we know that
__onUnknownMethod__ may need to be called?". Well, we can't do that,
because we don't know when __onUnknownMethod__ will be bound on an
ancestral prototype of the holder object of the property being retrieved.
We could generate an optimized stub, and then later an ancestral prototype
object modified to bind __onUnknownMethod__, and the optimized stub would
have no way of knowing, short of always guarding against all shapes in the
proto chain of every CALLPROP/CALLELEM, which is worse than the
primitive-value check described previously.
This is a huge amount of pain and complexity for handling a very rare
corner case. Unlike most corner cases which can be easily guarded against,
this feature forces additional checks in common hot-paths, and there's no
way around it. Baseline has several GetProp and GetElem stubs that would
need to be modified in this way. Ion has several variants of each as well.
This pain can be reduced by either removing __noSuchMethod__ entirely, or
by reducing its scope so that it only gets called for nonexistant
properties (as opposed to getting called for both nonexistant and
primitive-valued properties).
Combining the above argument with previously presented arguments, the
reasons for removal are:
1. It's a non-standard extension and it's not going to get standardized.
2. A good amount of its functionality can be implemented using
Object.prototype.__proto__ = new Proxy(...), which has the additional boon
of being standardized.
3. It adds a lot of unnecessary complexity to the JITS, bloats the
generated jitcode, and slows down hot paths.
I'm open to either removal or limiting its behaviour to only non-existant
properties, but I want to get moving ahead with at least one of those two
options.
My vote is for removal.
Cheers.
Kannan
______________________________**_________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@**lists.mozilla.org<[email protected]>
https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
