Re: [webkit-dev] Proposal to limit the size of the captured exception stack

> On Mar 28, 2017, at 9:55 PM, Mark Lam wrote: > > Matt, > I tested this on Firefox and Chrome and saw that Chrome captures up to 200 > frames. I don’t see Firefox capturing frames at all when not throwing an > Error. Were you looking at Error.stack for Firefox when you

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Matt, I tested this on Firefox and Chrome and saw that Chrome captures up to 200 frames. I don’t see Firefox capturing frames at all when not throwing an Error. Were you looking at Error.stack for Firefox when you came up with the 128 frames number? Maybe there’s a Firebug option I’m not

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Currently, there’s no way for the developer to change this. We can certainly make it an option that the Inspector can change if desired. Mark > On Mar 28, 2017, at 7:35 PM, Matt Baker wrote: > >> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen >

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen wrote: > > Does the separate exceptionStackTraceLimit mean that if a developer gets a > truncated stack trace in the Web Inspector, there’s no way for the developer > to remedy that? Is that what other browsers’ developer tools

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Does the separate exceptionStackTraceLimit mean that if a developer gets a truncated stack trace in the Web Inspector, there’s no way for the developer to remedy that? Is that what other browsers’ developer tools do? Geoff > On Mar 28, 2017, at 4:09 PM, Mark Lam wrote: >

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

To follow up, I’ve implemented the change in r214289: .org/r214289>. Error.stackTraceLimit is now 100. I also implemented a separate exceptionStackTraceLimit for stack traces captured at the time of throwing a value (not to be confused with Error.stack

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

@Geoff, my testing shows that we can do 200 frames and still perform well (~1 second to console.log Error.stack). Base on what we at present, I think 100 is a good round number to use as our default stackTraceLimit. > On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak wrote: >

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

> On Mar 17, 2017, at 11:09 AM, Mark Lam wrote: > > Thanks for the reminder to back observations up with data. I was previously > running some tests that throws StackOverflowErrors a lot (which tainted my > perspective), and I made a hasty conclusion which isn’t good.

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Thanks for the detailed write-up. The main thing that sticks out to me in this data is that Safari defaults to capturing a stack that is, in the worst case, roughly 3000X larger than the stack in IE and Chrome. That’s a big difference. I think this could be a real website compatibility problem

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Thanks for the reminder to back observations up with data. I was previously running some tests that throws StackOverflowErrors a lot (which tainted my perspective), and I made a hasty conclusion which isn’t good. Anyway, here’s the data using an instrumented VM to take some measurements and a

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

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

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

> On Mar 16, 2017, at 10:09 PM, Mark Lam 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