Just found this note from Craig Silverstein regarding ITIMER_PROF that is currently used in platform-linux:
"for ITIMER_PROF (and ITIMER_VIRTUAL): you get one tick per "<interval> CPU seconds consumed" [...]. The thread which causes the timer to run down to 0 gets hit with the signal, and [...] the profiler ticks will be distributed across multiple threads in proportion to their CPU usage." (full version here: http://code.google.com/p/google-perftools/issues/detail?id=106#c2) So, when JS is being actively executed (as in case of V8's shell, or in Chromium running e.g. a benchmark), SIGPROF is delivered to VM's thread with high probability. That's why it looks "working." But in case of an idle VM, SIGPROF will be delivered to another currently active thread, possibly causing a crash, especially if an application is compiled in debug mode, with all assertions from 'frames.*' enabled (as it's done for tests running on Chromium's buildbot.) To address a case of multiple threads, I think we can use thread list maintained by Top. I will try to implement it tomorrow. On Wed, Sep 2, 2009 at 18:11, Mikhail Naganov<[email protected]> wrote: >> Why is it called on another thread? > > Actually, POSIX specifies that in a multithreaded applications a > signal sent to a process is delivered to an arbitrary thread that > isn't blocking the signal. This was quickly revealed on Mac, where > initially profiling didn't worked on Chromium at all just because > renderer thread had almost never received SIGPROF signal. On Linux for > some reason SIGPROF is often delivered to a renderer, but not always. > >> From what I can see this will only work when V8 is only ever used from >> one thread, as is the case for the Chromium renderer process. However if >> different threads are using V8 then this will only get samples from one >> of these. > > But, e.g. in Windows implementation there is only one profiled thread, > and there can't be more, because Ticker (derived from Sampler) has a > single instance in Log. > > > I can try to look for another implementation. The common practice is > to block all unneeded signals in the main thread (and this property > will be inherited by child threads), and then only unblock signals in > threads where this is needed. However, as V8 is a library rather than > application, this isn't look feasible. > > On Wed, Sep 2, 2009 at 14:32, <[email protected]> wrote: >> Why is it called on another thread? >> >> http://codereview.chromium.org/171115 >> > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
