827404 - Consider doing a slightly slower path for DOM stuff when we can't do the proto chain check at compile time

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is not worth worrying about until bug 827396 is fixed.  Once that happens, we should remeasure what's going on with things like dromaeo's dom-traverse.

What I suspect might happen is that we'll run into issues with limits on the size of TI barrier typesets.  And if that happens it may be worth looking into something where we deoptimize to a "unknown DOM type" type, so that we can guarantee it plays nice, and then do the "implements this interface" check in jitcode.  That would require us to build some DOMClass knowledge into the JIT, which we've kinda avoided so far, but we can worry about that then.

The reason it would be faster to do the uwnrap in the JIT is that it can bake in things like whether the slot is fixed (which it totally is), and can avoid checking for things like whether it's a DOM object (because TI will keep tracking that).  Furthermore, it can avoid the extra function call imposed by our current generic* setup.  Of course the cost is extra jitcode, but it shouldn't be much: Needs to load the jsclass*, read a compile-time-constant offset from it, and compare to a compile-time constant...

Comment 1

[Mayank Bansal]

Is there a path forward here, or should we close this?

Comment 2

[Nicolas B. Pierron [:nbp]]

If I understand correctly, the concern is how do we coalesce multiple DOM calls into a generic DOM call without falling back to a generic JS call.

TI being removed this issue is no longer something to worry about.

However a similar issue might happen with Baseline ICs, and a solution to this problem might be added as part of the IC fallback logic or as part of the WarpOracle, If this is not already the case.