1707723 - [meta] Investigate CacheIR opportunities in ReactDOM

Status: NEW

(Core :: JavaScript Engine, task, P3)

Description

[Iain Ireland [:iain]]

I used Caroline's CacheIRHealthReport tool to capture information about non-monomorphic CacheIR on Facebook, and then manually filtered out everything that wasn't ReactDOM.

I'm writing down my list of potential opportunities in this bug. I'll open separate dependent bugs for any of those opportunities that we actually pursue.

1. Comparisons: It's common for comparison ops (StrictEq, StrictNe, And, Or, JumpIfFalse, etc) to have both null/undefined stubs and object stubs. We don't currently have a nice way to unify that into a single monomorphic stub.

2. GetGName: We have a lot of megamorphic ICs where every stub has identical code:

   GuardShape
   LoadObject
   GuardShape <-- only the shape being guarded here differs
   LoadSlot/Getter/etc
   

   This can occur if the shape of the global changes (because we define a new global variable) after we attach. In this case, we will attach a new IC, and none of the remaining ICs will ever succeed again. If it happens 6 times, we will go megamorphic with stub counts of N/1/1/1/1/1 (the entry count for the non-first stubs is incremented on failure).

   We can fix this by removing all the non-first ICs when attaching GetGName, or by using a fuse instead of a GuardShape.

3. There were a variety of GetProp ICs where stub folding (bug 1671228) looked like it would be helpful. However, I've previously tested stub folding on Facebook without seeing any measurable improvement, so I'm not too optimistic. One caveat: stub folding could also kick in (uselessly) in the GetGName case above, so if that's slowing us down, we could hypothetically see an improvement after fixing the GetGName problem.

4. We fail to attach a SetProp if the object has an addProperty hook. One example: the createTextInstance call here calls createTextNode and then uses precacheFiberNode to set a property on the resulting object. That object is a DOM wrapper, which now needs to be preserved, which is done using an addProperty hook. This IC is therefore immediately generic. This particular case might not be too bad, because I think we only set this property once per object, but if we are regularly setting properties on DOM objects, this could maybe be a big deal.