Can you be more specific about the motivation here? Do we have any motivating examples that will tell us wether time+memory were unacceptable before this change, or are acceptable after this change?
In our motivating examples, does Safari use more time+memory than other browsers? If so, how large of a stack do other browsers capture? We already limit the size of the JavaScript stack to avoid performance problems like the ones you mention in many other contexts. Why is that limit not sufficient? Did you consider implementing Chrome’s Error.stackTraceLimit behavior? Geoff > On Mar 16, 2017, at 10:09 PM, Mark Lam <mark....@apple.com> wrote: > > Hi folks, > > Currently, if we have an exception stack that is incredibly deep (especially > for a StackOverflowError), JSC may end up thrashing memory just to capture > the large stack trace in memory. This is bad for many reasons: > > 1. the captured stack will take a lot of memory. > 2. capturing the stack may take a long time (due to memory thrashing) and > makes for a bad user experience. > 3. if memory availability is low, capturing such a large stack may result in > an OutOfMemoryError being thrown in its place. > The OutOfMemoryError thrown there will also have the same problem with > capturing such a large stack. > 4. most of the time, no one will look at the captured Error.stack anyway. > > Since there isn’t a standard on what we really need to capture for > Error.stack, I propose that we limit how much stack we capture to a practical > size. How about an Error.stack that consists of (1) the top N frames, (2) an > ellipses, and (3) the bottom M frames? If the number of frames on the stack > at the time of capture is less or equal to than N + M frames, then > Error.stack will just show the whole stack with no ellipses. For example, if > N is 4 and M is 2, the captured stack will look something like this: > > foo10001 > foo10000 > foo9999 > foo9998 > … > foo1 > foo0 > > If we pick a sufficient large number for N and M (I suggest 100 each), I > think this should provide sufficient context for debugging uses of > Error.stack, while keeping an upper bound on how much memory and time we > throw at capturing the exception stack. > > My plan for implementing this is: > 1. change Exception::finishCreation() to only capture the N and M frames, > plus possibly 1 ellipses placeholder in the between them. > 2. change all clients of Exception::stack() to be able to recognize and > render the ellipses. > > Does anyone object to doing this or have a compelling reason why this should > not be done? > > Thanks. > > Mark > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
