Ah. I tried this without locking before but got a variety of crashes. I'll try again with ReleaseStore.
On Sat, Sep 25, 2010 at 04:41, Mikhail Naganov <[email protected]>wrote: > 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
