Maximally minimal stack trace standardization

Sam Tobin-Hochstadt samth at cs.indiana.edu
Mon Sep 29 14:05:23 PDT 2014


On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
>
>> On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu> wrote:
>>
>> I think this would be a mistake -- as I mentioned, there are a number
>> of possible strategies for stack traces w/ proper tail calls,
>
> But we should spec one of them, particularly if we want to move towards returning the stack trace as structured data. I think it would be good for implementations to be consistent and for the stack trace to not vary depending on which optimization tier you ended up in.
>
>> and as
>> Steve Fink mentioned, these also arise when considering inlining and
>> other optimizations.
>
> Nope. Inlining and other optimization a don't typically wreak the havoc on stack traces that TCO does.

A lot of time spent staring at C stack frames where calls have been
inlined away disagrees.

>> We shouldn't prevent implementations from trying
>> to experiment with what works best here.
>
> Is there something concrete that it would prevent anyone from trying?

If we mandate that we get exactly the same stack frames from every
implementation, which is what you are suggesting, then that would
prevent (some forms of) experimentation. Especially experimentation
that would produce _better_ stack traces than what you suggest
mandating.

Sam

>>
>> Sam
>>
>>> On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>>> Another way to make this (somewhat) testable is to require specific
>>> error.stack behavior for TCO.  For example, a call in tail position may
>>> require that the caller does not show up in the stack trace.
>>>
>>> -Filip
>>>
>>>
>>> On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu>
>>> wrote:
>>>
>>> On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller <erights at google.com> wrote:
>>>
>>> The issue is the asymptotic space consumption almost-contract. The reason I
>>> say "almost" is that conformance of an implementation is not testable.
>>> Currently, the spec says nothing about when an implementation might run out
>>> of storage.
>>>
>>> So we (at least I) mean normative only in the following sense: When someone
>>> writes an algorithm in ES6 using, say, bound functions in a loop, what
>>> claims may they validly make about the space complexity of their program?
>>> The specification should help answer such questions, sometimes.
>>>
>>> Note that I distinguish here between "the space complexity of their program"
>>> and the space usage growth when their program is run on an actual
>>> implementation. Again, conformance with any requirement on the latter is not
>>> testable.
>>>
>>>
>>> I think we can make it testable.
>>>
>>> We'd consider it a spec violation (at least, I would), if this program
>>> ran out of space, ever:
>>>
>>>   var i = 0;
>>>   while (1) {  i++; };
>>>
>>> similarly, this program should never run out of space:
>>>
>>>   var i = 0;
>>>   function f() { i++; return f(); }
>>>   f();
>>>
>>> If we write a test that checks counting to a specified number, I think
>>> test262 can adequately test this behavior.
>>>
>>> Sam
>>>
>>>
>>>
>>>
>>> On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
>>> wrote:
>>>
>>>
>>>
>>> On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
>>>
>>> Allen Wirfs-Brock wrote:
>>>
>>> No particular reason an implementation can't optimize through that if they
>>> want to.
>>>
>>>
>>> The question is whether it should be normative. PTC is about observable
>>> asymptotic space performance (I keep saying :-P).
>>>
>>> /be
>>>
>>>
>>>
>>> What should be normative?  You guys probably should probably review the
>>> actual spec. language and see if you have any issues with it.  All the tail
>>> call action takes place in the spec. on the caller side. See
>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
>>> and
>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
>>>
>>> The resources requirements of a function are represented by its "execution
>>> context".  PrepareForTailCall says the the caller's "execution context" is
>>> discarded before invoking the callee's [[call]] internal method.  [[Call]]
>>> for bound functions does not create a new "execution context" so there is no
>>> associated specified resource consumption that needs to be optimized away.
>>> At least as far as the spec. is concerned, bound functions (whether strict
>>> or sloppy) have no impact on TCO.
>>>
>>> I can't imagine what you would want be to try to say about non-EMCAScript
>>> functions. Their internal "call" semantics is determined by the semantics of
>>> their implementation language.
>>>
>>> Allen
>>>
>>>
>>>
>>>
>>>
>>> --
>>>   Cheers,
>>>   --MarkM
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>


More information about the es-discuss mailing list