Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fwd: Is dyntamic super binding really too expensive?
24 views
Skip to first unread message
Jason Orendorff
Apr 5, 2013, 9:05:11 AM4/5/13
to JS Internals list
Ion team, would you take a look at this, please?
> From: Allen Wirfs-Brock <all...@mozilla.com>
> Subject: Is dyntamic super binding really too expensive?
> Date: March 28, 2013 12:32:33 PM CDT
> To: Jason Orendorff <joren...@mozilla.com>
> Cc: Brendan Eich <bre...@mozilla.com>
>
> ES6 currently specifies that any method that uses super has a static reference to the "home" object that is the starting point (actually, minus 1) of its super property lookups. This approach was taken to avoid adding the overhead of an additional "where found" implicit argument to every function call. However, it introduces various observable complications when such functions are dynamically moved around by JS code.
>
> In the comments to https://gist.github.com/getify/5253319 I discussed this and tried to defend the current design choice on the performance basis. However, in the process it raised some doubts in my mind whether there really is a significant perf issue with dynamic super binding. I can think of various ways that at the implementation level I might be able to make that cost approach 0. For example, if an actual property lookup is performed both the actual this value and the "home" object of the resolved method should already be available. In a register rich environment (x64, etc.) I can imagine structuring the calling convention such that "home" is implicitly passed in a register and only super-using callee's would need to capture it.
>
> Obviously, when aggressive interprocedural analysis and/or inlining is performed the home inplicit argument overhead could be eliminated. The only case I'm less sure about is when PIC based dispatching is performed. I'm not up to speed on what the PIC look like for various modern engines but it seems likely that a PIC needs to capture the "home" reference and that it also could be passed as a 0 cost implicit parameter.
>
> So, here's my question. Can we convince ourselves that a typical JS engine could reasonable approach 0 cost passing of a "where found" implicit parameter to method calls. Even more concretely can you see how that might be accomplished within Spider Monkey? If it's plausible, we might be able to have a cleaner observable ES6 semantics for functions that reference super.
>
> What do you think?
>
> Allen
>
> From: Allen Wirfs-Brock <all...@mozilla.com>
> Subject: Is dyntamic super binding really too expensive?
> Date: March 28, 2013 12:32:33 PM CDT
> To: Jason Orendorff <joren...@mozilla.com>
> Cc: Brendan Eich <bre...@mozilla.com>
>
> ES6 currently specifies that any method that uses super has a static reference to the "home" object that is the starting point (actually, minus 1) of its super property lookups. This approach was taken to avoid adding the overhead of an additional "where found" implicit argument to every function call. However, it introduces various observable complications when such functions are dynamically moved around by JS code.
>
> In the comments to https://gist.github.com/getify/5253319 I discussed this and tried to defend the current design choice on the performance basis. However, in the process it raised some doubts in my mind whether there really is a significant perf issue with dynamic super binding. I can think of various ways that at the implementation level I might be able to make that cost approach 0. For example, if an actual property lookup is performed both the actual this value and the "home" object of the resolved method should already be available. In a register rich environment (x64, etc.) I can imagine structuring the calling convention such that "home" is implicitly passed in a register and only super-using callee's would need to capture it.
>
> Obviously, when aggressive interprocedural analysis and/or inlining is performed the home inplicit argument overhead could be eliminated. The only case I'm less sure about is when PIC based dispatching is performed. I'm not up to speed on what the PIC look like for various modern engines but it seems likely that a PIC needs to capture the "home" reference and that it also could be passed as a 0 cost implicit parameter.
>
> So, here's my question. Can we convince ourselves that a typical JS engine could reasonable approach 0 cost passing of a "where found" implicit parameter to method calls. Even more concretely can you see how that might be accomplished within Spider Monkey? If it's plausible, we might be able to have a cleaner observable ES6 semantics for functions that reference super.
>
> What do you think?
>
> Allen
>
0 new messages