Currently, JSOP_IN is not really optimized well either in Baseline or in Ion. The fastpath cases for JSOP_IN are basically identical to the JSOP_GETPROP fastpaths: native properties, proto chain native properties, and dense elements. Ion optimizes dense element checks on arrays, but nothing else. Baseline optimizes none of these cases - it has a fallback stub but the stub generates no optimized stubs. Intuitively, I expect polymorphism at these sites. For a property access |x.foo|, it's far more likely that the developer is using the syntax assuming that the foo property exists, and expecting all objects to contain that property. For property checks |'foo' in x|, it's far more likely that the developer expects that |x| may or may not contain 'foo', indicating likely polymorphism at that site. Here are the various optimization paths available: 1. Add optimized baseline IC stubs. Baseline can generate optimized stubs for: - existing direct native properties (using a shape guard) - existing proto properties (taking advantage of telescoping shapes, so two shape guards - one on the object and one on the holder) - nonexisting properties (using a full proto-chain shape guard) - dense elements 2. Add optimized Ion cases for property checks. - use TI to optimize accesses. This can only be done for definite properties. For monomorphic sites, this can be optimized into a constant. For polymorphic sites, we can generate TypeGuards for each object type showing up. - use BaselineInspector to optimize accesses. As with the GetProp, we can take a look at the various stubs attached by the Baseline script, and use that to encode a polymorphic shape guard. - use an IonCache IC, and generate optimized Ion stubs. Now, the highest-impact of these is going to be the last one: add an Ion IC, write IonCache stubs for the most common cases. Then, after that, the next highest impact will be the Baseline ICs + Ion ShapeGuard stuff. Then the TI-based optimizations. From a difficulty perspective, the baseline stubs are probably the easiest to start with and understand.
I'll take this, thanks.
Assignee: nobody → tchou
I just traced the code a bit, probably I should start from baseline stubs. And I guess I need to update DoInFallback() to have some similar things as DoGetPropFallback()? For the polymorphism you mentioned, is there any operaion can be a reference? There're also things I don't quite understand, for instance: "shape guard", is there a glossary or document? Googled but didn't find one. Thank you :)
Not sure should I write down what have I done for monitoring my progress, I read a blog http://mrale.ph/ to pick some knowledge.
Yeah, starting with Baseline is reasonable. A shape-guard is just what we call the technique where we check the shape of an object at runtime to determine it's properties. I would create a sub-bug (blocking this one) just for the Baseline optimization, and work on that. For starters, you can take a look at the optimized stub ICGetProp_Native, and write a similar one ICIn_Native. ICIn_Native will be very similar to ICGetProp_Native, except instead of retrieving the value from the object, it'll just return a constant BooleanValue(true).
Unassigned myself as I am not working on this.
Assignee: janus926 → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.