I was looking into why we're 4x slower than Safari on prototype.js stuff, both on dromaeo and slickspeed. It looks like prototype has a common pattern in many of its functions like this: adjacent: function() { var args = $A(arguments), element = $(args.shift()); // other stuff } Where $A is defined as: function $A(iterable) { if (!iterable) return []; if (iterable.toArray) return iterable.toArray(); var length = iterable.length || 0, results = new Array(length); while (length--) results[length] = iterable[length]; return results; } We abort on that while loop, since the arguments stack frame is not reachable. Given that, do we ever manage to trace any loop which contains a call to a function that calls $A?

I should note that I replaced those last three lines with: return Array.slice(iterable); but things are still slow...

Though slow for apparently other reasons; the aborts on that line go away.

Filed bug 532696 on that.

I think it's possible to trace this without too much difficulty. Just as with closures, in this out-of-reach case on later runs the frame of the argsobj could be either in the interpreter or in an outer trace. The interpreter uses a special setter which I think could be sped up by specializing, as you did for closures. If the argsobj is created on trace, then its private is a tagged pointer to an ArgsPrivateNative that should work. I think there is a tricky case if the argsobj was created in the trace entry frame of an outer trace. In that case, you have to make sure to read from the trace native stack area, not the interpreter things. That shouldn't be too hard--we just have to set the private to point to the ArgsPrivateNative as we import the argsobj. LeaveTrace will fix it back already.

No tracer; we should have no problem compiling this now.