Somewhat gross, but could you condition the generation of that code on seeing a __noSuchMethod__ property set anywhere in the compartment or whatever the right unit of isolation is? IIRC we did this for mutated Array.prototype at one point.
Mike On Tuesday, September 10, 2013, Kannan Vijayan 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 > [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
