Well, I've got your idea, but I don't like using mutexes with sampler, because it must be as lightweight as possible. As profiled_thread_ is of an atomic type, you can really avoid locks when using it. There is an OS::ReleaseStore function for setting atomic values and making sure that this write is visible to all CPUs. You only need to make a local copy of profiled_thread_ inside Runner to make sure that it doesn't change under your feet.
On Fri, Sep 24, 2010 at 04:16, malcolm handley <[email protected]> wrote: > Ah, thanks. I had missed the memcpy in Top::RestoreThread and > Top::ArchiveThread. I tried the profiler on linux but had some trouble with > deadlocks (before making any changes to the code). > Attached is a patch that makes the Mac version of Sampler sample the thread > that holds the global lock rather than always sampling the main thread. It > compiles on Linux but I haven't tested it elsewhere. > If there is any chance that you'd accept this patch I'd be happy to make > changes or corrections. > > On Wed, Sep 22, 2010 at 10:57, Mikhail Naganov <[email protected]> > wrote: >> >> Well, I believe, it is get restored, see ThreadManager::RestoreThread >> method. >> >> Anyway, there is a small hack you can exploit: in >> SafeStackFrameIterator constructor, change is_valid_top_ to be always >> false, and stack sampling will be always done using values from >> registers, not from top. However, this might result in incomplete >> stack traces. >> >> On Wed, Sep 22, 2010 at 21:43, malcolm handley >> <[email protected]> wrote: >> > Thanks. That's good to know. I'll give linux a try. >> > I fear, though, that it's not going to work completely. >> > StackTracer::Trace >> > gets the JS SP for the thread identified by Top::GetCurrentThread. As >> > far as >> > I can tell GetCurrentThread actually returns the main thread. (It >> > returns >> > Top::thread_local_, which has a comment saying "The context that >> > initiated >> > this JS execution" and does not seem to be adjusted when switching >> > threads.) >> > I'll look into passing a thread to StackTracer::Trace. >> > >> > On Wed, Sep 22, 2010 at 10:20, Mikhail Naganov <[email protected]> >> > wrote: >> >> >> >> Hi Malcolm, >> >> >> >> Yes, no one wanted to profile multiple VM threads yet. >> >> >> >> On Linux, profiling multiple threads may even work already -- try it. >> >> There is a function 'IsVmThread' in platform-linux.cc which checks, >> >> whether the thread that a signal handler has been called upon is a VM >> >> thread or not. >> >> >> >> On Mac & Windows, things are more complicated, because we use a >> >> dedicated profiling thread that periodically stops and samples the VM >> >> thread. So to make this work for multiple threads case, one will need >> >> to track a list of VM threads in the sampler. >> >> >> >> On Wed, Sep 22, 2010 at 20:53, malcolm handley >> >> <[email protected]> wrote: >> >> > I have multiple threads using v8 (correctly guarded by v8::Locker as >> >> > far >> >> > as >> >> > I can tell) and I'm interested in using v8's profiler. The comment >> >> > above >> >> > the >> >> > Profiler class in log.cc states that "The Profiler samples pc and sp >> >> > values >> >> > for the main thread.". Is there a technical reason for that or is it >> >> > just >> >> > that no one has wanted to profile other threads yet? It seems to me >> >> > that >> >> > profiling whichever thread holds the global lock could be productive >> >> > but >> >> > I'd >> >> > love any feedback about fruitful ways to proceed (or reasons not to). >> >> > >> >> > -- >> >> > v8-users mailing list >> >> > [email protected] >> >> > http://groups.google.com/group/v8-users >> >> >> >> -- >> >> v8-users mailing list >> >> [email protected] >> >> http://groups.google.com/group/v8-users >> > >> > -- >> > v8-users mailing list >> > [email protected] >> > http://groups.google.com/group/v8-users >> >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
