Error stack strawman

John Lenz 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_
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160218/8145704e/attachment.html>


More information about the es-discuss mailing list