Method calls run at machine speed - and a real crash fixed on the way

Most page code is written as objects with methods - o.doThing(x) where doThing reads this.something. Until now the fast tier could compile the loop around such a call but had to hand the call itself back to the slower path. It now compiles the whole thing to native machine code: on the method benchmark that is about nine times faster than the previous tier. Getting there meant fuzzing the new path against the plain interpreter across tens of thousands of random programs, and that fuzzing found a genuine crash that had been shipping quietly: a method that read one of its object's fields inside an if or a ?: could jump to the wrong instruction and take the page's script down. That is fixed, with its own test. And the security story behind all this speed is now written down and machine-checked: the common fast paths generate no executable memory at all, the one tier that does is write-once and never writable-and-executable at the same time, and all three tiers are proven to compute bit-for-bit identical answers every release. This is a speed-and-correctness release, so the parity figures move only where the work honestly earns it (the JIT sub-score).