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
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:
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
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
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
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
- 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
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
- 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
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?
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
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
12 matches
Mail list logo