Re: Should we build a new in-process unwind library?

2014-01-05 Thread Benoit Girard
My goal is to make SPS's stack easier to grab. SPS provides native stack (if possible) plus pseudo stack. So it generally has more data then just a native stack and is much more portable. That being said making the unwind library independent is a win-win. On Thu, Jan 2, 2014 at 11:03 AM, Jim

Re: Should we build a new in-process unwind library?

2014-01-02 Thread Jim Chen
This is great! Thanks for working on it! Can the new library be used independently outside of SPS? For hang detection (bug 909974) we'd like to have the ability to unwind the hung thread's stack, and this library would be perfect for that. Cheers, Jim On 12/19/13 2:04 PM, Julian Seward wrote:

Should we build a new in-process unwind library?

2013-08-30 Thread Julian Seward
For a while now, Fennec and Linux-desktop nightlies have had the built-in SPS-based time profiling using native stack unwinding. The unwinding is done using our in-tree Breakpad copy, which includes a bunch of speedup patches that are slowly making their way upstream. What we have works, but is

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Robert O'Callahan
On Fri, Aug 30, 2013 at 8:58 PM, Julian Seward jsew...@acm.org wrote: I am not sure how to deal with (4). Really it's completely unrelated to the unwind mechanism -- it has to do with SPS' sampling policy at the level above. There have been some ideas floated around to detect when a thread

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Robert O'Callahan
On Fri, Aug 30, 2013 at 9:41 PM, Julian Seward jsew...@acm.org wrote: That said, AFAICS the core problem is that once a thread blocks and we drop the sampling rate, we have no obvious (direct, notification-based) way to know when it has resumed, and hence are in danger of losing high-frequency

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Jeff Muizelaar
On 2013-08-30, at 4:58 AM, Julian Seward wrote: I am very tempted to create a new custom unwind library designed specifically to support SPS. It needs to be fast, lower-footprint, and multithreaded. Unlike Breakpad, it will -- at least initially -- avoid supporting all Tier 1 targets, and

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Nathan Froyd
- Original Message - On 08/30/2013 11:07 AM, Robert O'Callahan wrote: Being able to sample uniformly whether or not the thread is in a syscall is important sometimes, so let's not lose that. I am not proposing to lose that facility. Am only proposing (really, merely parroting

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Ehsan Akhgari
On Fri, Aug 30, 2013 at 9:27 AM, Nathan Froyd froy...@mozilla.com wrote: - Original Message - On 08/30/2013 11:07 AM, Robert O'Callahan wrote: Being able to sample uniformly whether or not the thread is in a syscall is important sometimes, so let's not lose that. I am not

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Nathan Froyd
- Original Message - Depending on how deep the call stack is and how frequently we push and pop stack frames, being able to not unwind some number of frames can be a significant savings. Isn't this assuming that the stack frames are unique? How would you handle recursion under

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Ehsan Akhgari
On 2013-08-30 10:16 AM, Nathan Froyd wrote: - Original Message - Depending on how deep the call stack is and how frequently we push and pop stack frames, being able to not unwind some number of frames can be a significant savings. Isn't this assuming that the stack frames are unique?

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Ehsan Akhgari
On 2013-08-30 11:07 AM, Nathan Froyd wrote: - Original Message - Nevermind, I think your solution is talking about function addresses, not stack frames. If you think my solution is talking about function addresses, then I have explained something poorly. Why do you think it is

Re: Should we build a new in-process unwind library?

2013-08-30 Thread Steve Fink
On 08/30/2013 06:27 AM, Nathan Froyd wrote: - Original Message - On 08/30/2013 11:07 AM, Robert O'Callahan wrote: Being able to sample uniformly whether or not the thread is in a syscall is important sometimes, so let's not lose that. I am not proposing to lose that facility. Am only