Toshiyasu,
On Jun 10, 2009, at 2:24 PM, Toshiyasu Morita wrote:
Why does the arity check need to be in the caller, and not the callee?
The majority of call sites always call to the same callee, and we can
optimize these cases for calling that same function repeatedly.
Within the optimized path of the op_call, where we are linked to a
specific callee, we can statically determine at compile time that the
caller and callee have the same arity, and omit the dynamic arity
check altogether – which is a performance win. Within the callee
(where you might have been called from multiple call sites with
difference numbers of arguments passed) it is not clear how you would
implement such an optimization. But patches welcome as ever!
(btw, I was on your side on this one, the arity check in the callee
seemed more natural to me at first, until the benefits of performing
the check in the caller became clear. That said, from a design point
of view, fixing up arity at the call site can also makes sense in
matching (or at least being analogous to) calling conventions of other
languages. If you consider calling a JS function with too few
arguments as being akin to invoking a C++ method with some defaulted
parameters not-provided, then it is also the responsibility of code
generated for the call to such a method to ensure that values for all
declared parameters are passed.)
Consider: one function that is called from 10,000 places.
Arity check in the caller: 10,000 copies of the artity check.
Arity check in the callee: one copy of the arity check
You're not taking into account that we don't generate the arity check
inline, instead it is in a shared trampoline.
Consider: one hundred functions that are called from 10,000 places.
Arity check in the caller: 10,000 copies of the artity check.
Arity check in the callee: one hundred copies of the arity check
Arity check in a set of 3 shared trampolines (which is how the JIT is
currently implemented): 3 copies.
(3 due to the stages the call linking goes through, go see the code to
find out why!)
cheers,
G.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
