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