undefined | Better HN

0 pointsolliej16y ago0 comments

One of the big issues is that any JS function can technically walks its own call stack, which makes inlining very difficult, and for many of these tests the ability to inline is actually a fairly substantial advantage.

The basic problem faced by a JS engine is that if it wants to be able to inline a function it has to be able to either:

* Prove that it knows everything that the function may do -- in effect this means you can't inline any functions that themselves call functions, or any functions that interact with any values you can't consider constant, or identify before you enter the inlined code; or

* Have the ability to at any point in time reconstruct the call stack, and all arguments correctly.

One of these choices is exceedingly limiting in what you can do, and the other is vastly complex.

0 comments

2 comments · 2 top-level

sjs16y ago

As Mike Pall said: "None of the benchmarks make use of JavaScript's weird corners. And all of them can (or could) be reduced to simple constructs. So I wouldn't blame it on the language differences alone (maybe on the implementation)."

Only the use of such a feature should trip the "do it the safe but slow way" switch. Maybe that's not possible here though, I don't know that much about compiler optimization.

edit: I'm not implying it's easy either, but if it's possible the V8 team has the skills to implement it.

beagle316y ago

But 99.9% of JS code doesn't do that, so it should be optimized for that case.

LuaJIT keeps enough info around to go back to the interpreter at the moment anything goes different than previously traced -- I see no reason JS couldn't do the same.

j / k navigate · click thread line to collapse