Yeah I too need to be compatible with old versions of v8 because I've still 
got code on 0.10, I think you're right about writing a new profiler. The 
trouble is that most profilers ignore the benefits of being able to see the 
syscalls and the full C++ stack we're calling into. I actually think it's 
pretty poor for the cpu profiler to bail during GC, since this is a 
significant source of cpu churn that is important to know if you're 
optimizing a service. Out of curiosity, what are you using to take the 
backtrace? The stack can be naively walked, but there are a bunch of 
platform-specific nuances and maybe some issues if you use certain GCC 
optimizations. I was considering using libunwind though v8 already has some 
cross platform stack walking code in it.

On Monday, 4 January 2016 02:44:03 UTC-8, Ben Noordhuis wrote:
>
> On Mon, Jan 4, 2016 at 11:13 AM, Matt Esch <[email protected] 
> <javascript:>> wrote: 
> > When I say CPU profiler I mean the programmatic API. 
> > 
> > I'm familiar with most of the tools currently available for generating 
> flame 
> > graphs and have even written one myself based on ptrace for linux, but 
> > nothing is really good enough. I am looking for something that can be 
> > switched on and off on a production system without needing to start the 
> > process with special flags. 
> > 
> > The cpu profiler supplied by v8-profiler.h generates a cpu profile 
> artifact. 
> > To generate the cpu statistics v8 backtraces on an interval and then 
> > generate statistics from the backtraces. I would like access to the raw 
> data 
> > that's driving the cpu profiler. The raw set of backtraces with resolved 
> js 
> > symbols is enough to generate a flame graph and do other interesting 
> things. 
> > The other symbols for the native code can be resolved in the standard 
> way 
> > after the profile is generated. 
>
> The raw data isn't currently exposed.  You'd have to patch V8; maybe 
> you can get a patch accepted upstream. 
>
> FWIW, in StrongLoop's strong-agent product, we basically ended up 
> writing a C++-and-JS profiler from scratch based on V8's JITCodeEvent 
> API.  That was in part because we needed to be compatible with old 
> versions of node.js, it was easier to write a new profiler than 
> retrofit the old software with the requisite changes. 
>

-- 
-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to