Maximally minimal stack trace standardization

Filip Pizlo fpizlo at apple.com
Mon Sep 29 13:57:02 PDT 2014



> 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. 

> 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?

> 
> 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