Noticed this when reducing a v8-crypto correctness bug (it started crashing at some point). Consider this testcase: -- function f(o) { o.t; o.t; for(var i=0; i<100; i++) { } } function test() { var o = {t: 2}; f(o); o.t = {}; f(o); } test(); -- The second time we call f, the GetPropertyCache function invalidates its caller (f). Afaik, this patches the return address of the VM call to go to the bailout thunk. The problem is that the bailout/resume process expects the registers to be valid, but they are overwritten by the VM call. So we bailout to the interpreter with bogus values on the stack and the second "o.t" crashes, since o is invalid.

Yeah. We get away with the register push on the inline calls because, on an inline call, the register allocator spills all regs across the call. The only registers that will be referred to by the post-call snapshot are those for the return value from the inline call, and those are valid at the point that the invalidator-thunk runs. In the OOL path case we push the caller-save regs that are live and then perform a VM call via callVM. We then pop the caller-save regs back into their original locations. We're going to have to pass the live register set (from the safepoint, as given in informSafepoint) into the FrameInfo so that we know which registers are on the stack from the invalidation code.

Gary may have found a simpler testcase in Bug 716743.