The code for calling common getters and setters on property accesses currently looks at the current state of the VM to find the getter/setter and decide if it can be called. Since the VM state being inspected can change at any time this strategy won't work with off thread IonBuilder. Instead, baseline ICs can be inspected to find getters/setters which *might* be common, and IonBuilder can use these and any type information to determine whether the getter/setter will definitely be called.

Comment on attachment 823511 [details] [diff] [review] patch Review of attachment 823511 [details] [diff] [review]: ----------------------------------------------------------------- r=me with mistake addressed and retesting. Eventually, we may want to go to a model that allows us to do poly-inlining at these sites as we do with JSOP_CALL. This is a good first step towards that world. It also has the added benefit of removing the silliness with own-property getters being pig slow. \o/ ::: js/src/jit/IonBuilder.cpp @@ -5482,5 @@ > return true; > } > > -static bool > -CanEffectlesslyCallLookupGenericOnObject(JSContext *cx, JSObject *obj, PropertyName *name) Glad to see this go. Ionbuilder is in general too callous in its willingness to walk the proto chain a hojillion times. @@ +7587,5 @@ > + if (property.maybeTypes() && !property.maybeTypes()->empty()) > + return false; > + > + if (type->proto() == foundProto) > + break; This break goes directly into a |return false|? Isn't this a success case? @@ +7593,5 @@ > + } > + > + // The foundProto being searched for did not show up on the object's > + // prototype chain. > + return false; needs to go to if (!type) return false;