Closed
Bug 1046792
Opened 11 years ago
Closed 4 years ago
SpiderMonkey: optimize JSOP_IN
Categories
(Core :: JavaScript Engine: JIT, defect, P5)
Tracking
()
RESOLVED
FIXED
People
(Reporter: djvj, Unassigned)
References
Details
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.
Comment 2•11 years ago
|
||
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 :)
Flags: needinfo?(kvijayan)
Comment 3•11 years ago
|
||
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.
Reporter | ||
Comment 4•11 years ago
|
||
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).
Flags: needinfo?(kvijayan)
Updated•11 years ago
|
Status: NEW → ASSIGNED
Comment 5•9 years ago
|
||
Unassigned myself as I am not working on this.
Assignee: janus926 → nobody
Status: ASSIGNED → NEW
Updated•9 years ago
|
Priority: -- → P5
Comment 6•4 years ago
|
||
CacheIR has pretty extensive support for in
. We also transpile these instructions like LoadDenseElementExistsResult
in Warp.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•