Error stack strawman
concavelenz at gmail.com
Fri Feb 19 05:29:46 UTC 2016
On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo <nbdd0121 at hotmail.com> wrote:
> Andreas <rossberg at google.com> 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_
> 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
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
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss