Sampler is designed to deal with inconsistencies in VM state, because even in a single-threaded case, VM thread can be interrupted by the sampler at an arbitrary moment. That's why there are so many checks in SafeStackFrameIterator. If an inconsistent state is discovered by Sampler, it just skips taking a stack sample for this time -- not a big deal.
We also can fight inconsistency by ensuring that the Sampler has only a single reference for accessing VM data (this may include thread Id). Having a single point, it is easy to avoid locking: while the data is being modified, accessor reference points to old consistent data, then after the new data is ready, the point is being switched. Using ReleaseStore operation guarantees (via OS memory barriers), that all writes prior to switch have been actually written to memory, so all cores will read consistent values. On Fri, Sep 24, 2010 at 19:17, malcolm handley <[email protected]> wrote: > 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
