(Some Mozilla 1.9.1 work on DOM performance is in bug 407216.)
Bug: Too early for a bug. (Talk to jorendorff, brendan, jst, roc.)
Motivation: XPConnect glue code is a performance bottleneck.
Technical approach: Make the SpiderMonkey tracing JIT identify XPConnect methods and emit all the appropriate guards and instructions to inline the glue code (conversion of this from the JS wrapper to an XPCOM pointer of the appropriate type; argument conversion from JS to native types; the C++ virtual method call; return value conversion from native to JS types).
The inlined glue should be much faster than the XPConnect glue code we have, because it'll be specialized for the type and offset of the method being invoked. Once an XPConnect method call is jitted, it can be executed without looking at any metadata.
Risks: This depends on a tracing JIT landing in SpiderMonkey (soon enough to add this work afterwards).
There's a weaker approach that doesn't have this dependency. Regardless of whether SpiderMonkey does any JITting, XPConnect could use Tamarin's nanojit library to generate code to serve as SpiderMonkey getters, setters, and fast natives. This wouldn't be as fast though.
The other risk is the maintenance cost. With this change, some parts of the XPConnect and xptcall magic will reside in two places.