1046792 - SpiderMonkey: optimize JSOP_IN

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Kannan Vijayan [:djvj]]

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 1

[Ting-Yu Chou [:ting] (away)]

I'll take this, thanks.

Comment 2

[Ting-Yu Chou [:ting] (away)]

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 :)

Comment 3

[Ting-Yu Chou [:ting] (away)]

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.

Comment 4

[Kannan Vijayan [:djvj]]

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).

Comment 5

[Ting-Yu Chou [:ting] (away)]

Unassigned myself as I am not working on this.

Comment 6

[Tom S [:evilpie]]

CacheIR has pretty extensive support for in. We also transpile these instructions like LoadDenseElementExistsResult in Warp.