[webkit-dev] arm jit

[Gavin Barraclough]

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.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090610/cdbb155c/attachment.html>