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 proposing to lose that facility. Am only proposing (really, > > merely parroting Taras' suggestion) that it would be nice to have the > option > > of some kind of adaptive backoff for threads blocked in syscalls. > > One way of handling this is the following: When you take a sample, replace > the return address for the current stack frame with the address of a known > function inside your profile (call this a "trampoline function"). Now the > call stack looks something like: > > A --> B --> C --> D --Trampoline--> E > > where the sample was taken in E. The trampoline function enables us to > keep track of what some portion of the stack looks like without having to > unwind it. Unwinding on subsequent samples proceeds until we encounter a > frame whose return address is the trampoline function. At that point, we > know everything else above that frame is the same as whatever it was the > last time we took a sample. > > There are now three interesting scenarios of what can happen before we > take the next sample. > > 1) E does not return. It may call other functions, it may do some > computation, or it may just be blocked on a syscall. Whatever the case, we > take a sample, find that E's return address is our trampoline function, and > stop. > > 2) E calls F calls G, and then a sample is taken. Just prior to the > sample, we have: > > A --> B --> C --> D --Trampoline--> E --> F --> G > > The profiler fixes things up to do: > > A --> B --> C --> D --> E --> F --Trampoline--> G > > and we go about our merry way. > > 3) E returns. Instead of returning to D, it returns to our trampoline > function. Said function then replaces the return address of D's stack > frame with the address of the trampoline function, and returns to the > appropriate PC in D: > > A --> B --> C --Trampoline--> D > > This can happen several times (D returns to C, etc.). > > 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 this scheme? Cheers, -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
