On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo <[email protected]> wrote:
> Andreas <[email protected]> wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add that. A frame is created by the callee, > but that does not know how it got called. Funnelling through that > information would effectively require a hidden extra argument to _every_ > call. > > Placing a boolean flag theoretically should not introduce too much > overhead. If we are not going to indicate tail call some way, debugging > might be extremely difficult, and the stack result might be making no sense > at all. > This smells wrong to me from a performance perspective and seems like a painful cross cutting concern. You would basically be trading the gains from tail-calls improves for complexity and cost everywhere else (an extra parameter for every call means a shorter stack). For instance, VM/native interfaces would always need a proxy to provide or be modified to carry this bit. If it were implemented as a extra parameter, this means at least one slot or stack push. However, at the CPU level, it seems like you would be better pushing an return address for a special function that indicated the start of a sequence of tail calls. That way you trade only some complexity/performance for tail calls (an inspection of the last entry of the call stack) and some stack frame building complexity (to recognize this "special" frame). It been a long time since I've worked directly with assembly, stack frames, and calling conventions and don't know how feasible this would be on modern/unique CPU/GPUs that are likely to have JS VMs. > > --- > > As for how to distinguish between special code source, such as native, if > https://github.com/tc39/ecma262/issues/395 is resolved, we can use the > built-in module name for the "source" field, and hopefully we can reserve > some special built-in module name for native code, cross realm code, etc, > and then we can have a unified representation of all frames. > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
