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
