Speculative execution of JavaScript

[kmcallister]

There are points in the execution of a script where we can guess the result of an expensive operation, and continue on a speculative basis before the operation is complete. For example we can guess that an innerHTML write won't modify pure-JS variables, or that a client rectangle query will return the same result as last time.

We would need a way to snapshot and rollback SpiderMonkey state. We would also need to pause speculative execution when it's going to do something observable — mainly DOM writes, unless we have a speculation COW DOM in addition to the layout snapshots.

It's not clear this would be worth the (probably large) effort, but we could gather a little data first. For example, how often do client rectangle queries on real sites yield the previous value, and how much time is wasted waiting on them?

See also #1009.

[SimonSapin]

This reminds me of PyPy’s work on Software Transactional Memory where instead of a having Global Intepreter Lock, threads are executed in parallel, optimistically hoping that they will not conflict in reading/writing shared memory. If they do, all but one are "rolled back" and executed again.

From what I gather on PyPy’s blog, STM is still bleeding edge research at this point.

[SimonSapin]

http://pypy.org/tmdonate.html has a higher-level description of PyPy’s STM.

[kmcallister]

That's an interesting connection. There are also fairly mature STM implementations in Clojure and in GHC Haskell. They're pretty different from each other, too.

Clojure and Haskell provide semantics for explicit transactions, while we (and PyPy) would be implementing sequential semantics. So for example, it's less clear where our "commit" points are. We should look to the PyPy STM for guidance on this, except that it doesn't exist yet.

I found some papers on speculative JS: 1, 2, 3.

PJS also seems slightly related.

[kmcallister]

There's a speculative JS paper from Microsoft Research.