Escape analysis is blocking many optimizations, some of them are still to be done, such as stack allocation, store & load aliasing, or hoisting store at the end of loops. The last 2 optimizations would likely impact pdfjs.js:16933 (octane benchmark) in 2 locations, one being the scope chain which only need to be synced when we call into getToken (which captures the loop variable, and also block Bug 856178 in the same function), the second one (unlikely a perf issue) being the content of the program object which is constantly read. The escape analysis implies being able to link a declaration to the instruction which is escaping it. The way I am thinking for designing this technique is to add 2 MUse flags. One flag indicates that a use “isEscaped”, and the other that a use “mightBeTransitivelyEscaped” for stores. The fact of adding a flag on the MUse makes it easier than using the MInstructions flags, but implies that such flags need to be either updated during replaceOperand or maintained with a separate phase (which might be more costly). On the other hand, using MUse flags gives the ability to implement a MEscapeIterator which follow the MUses' flag (“isEcaped”) to iterate over all escaping instructions, which might not be obvious to discover once instructions are boxed & unboxed for whatever reasons. Note: Bug 661374 suggests adding escape analysis to the bytecode.