I share the desire for the sampler to be as light and fast as possible but I wasn't able to convince myself that an atomic copy of profiled_thread_ was sufficient. For example, what about the Top::thread_local_, which is used to find the JS SP? It seemed bad, or at least unpredictable, for that to get out of sync with profiled_thread_.
On Fri, Sep 24, 2010 at 03:11, Mikhail Naganov <[email protected]>wrote: > 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
