On Sep 21, 2010, at 12:57 PM, Maciej Stachowiak wrote:
On Sep 21, 2010, at 11:37 AM, Holger Freyther wrote:
On 09/22/2010 02:09 AM, Oliver Hunt wrote:
In the general case this would require being able to convert from inlined code to a 'correct' call stack at some arbitrary point
argh, I had hoped that such things would be only necessary when we have a debugger attached. This mean besides what maciej had said, we will need to remember that this range of instructions belongs to a inlined call and be able to generate the virtual call record.
Can one write to arguments, callee and such?
arguments can be shadowed or individual arguments can be modified. You can statically detect when a function might use "arguments" and just avoid inlining it; the big problems are arguments.caller and func.arguments, since those can be done by functions called by the inlined function, so it's hard (maybe impossible) to statically prove they won't happen.
There is a subset of functions that you can prove makes no calls, so in that case, inlining would be safe without excessive magic. But this would exclude property access for instance, since getters and setters can turn any property access into a call. So only functions that stick to simple arithmetic could be inlined.
I wonder (and will try to measure based on sunspider and other test content) how many functions occur like function f(x) { return x +2; } or even fully constant. Is there any classification of the complexity of functions at parse time?
I wonder how ES5 strict mode affects the challenge of doing inlining correctly.
In strict mode arguments aren't live, arguments.callee, function.caller and function.arguments throw for any strict function.
Regards, Maciej