Error stack strawman

John Lenz concavelenz at
Fri Feb 19 05:29:46 UTC 2016

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo <nbdd0121 at> wrote:

> Andreas <rossberg at> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list