Right now type inference info related to arguments accesses is really bad. When someone accesses ARGUMENTS or any property of the args, we know nothing about it. Fixing this so we know when we're definitely accessing the script's arguments will make generating inline paths easier, and make it possible to handle the earley-boyer pattern which copies 'arguments' into a local before accessing them (we don't want to make the arguments object in such cases). function sc_list() { var res = null; var a = arguments; for (var i = a.length-1; i >= 0; i--) res = new sc_Pair(a[i], res); return res; } What I think we need: - Be able to prove statically that a script cannot override its arguments. I think all this needs is scanning for SETNAME "arguments" in the script's body, as trying to override the arguments by setting a property of the function has no effect (phew...). This is needed for the earley-boyer pattern. - Statically guard against scripts mucking with their arguments objects, adding new properties, changing the length, etc. This would allow accesses known to be on the arguments object to go straight to the stack frame. This covers type information, but to handle the earley-boyer pattern we would also need some runtime changes to handle interpreter rejoins. In sc_list above, the interpreter expects 'a' to hold the arguments object but if we rejoin from JIT code somewhere in the script we need to construct the args and patch 'a' with that value.

A script can override its arguments if the script isn't strict mode code and you see a call to 'eval' in it.

I seem to remember that this has improved. Am I wrong, or can we close this?

Yeah, for a long time now (including with JM+TI) we have had magic arguments values that we know definitely hold the arguments array without any need to explicitly create the arguments object.