Node 8 - missing stacks #76
Comments
|
#75 may be relevant |
|
This is macOs but anecdotally I've seen same on linux Not an interpretation problem on 0x part, stacks simply aren't being captured |
|
Some of these look like cases where there was no frame pointer pushed onto the stack, as often happens when "-fomit-frame-pointer" is used to compile C code. I'm not sure if that's what's going on. It's also possible that the newer version of V8 no longer pushes frame pointers upon entry into its functions. If true, I think that would basically destroy the ability to profile from tools like DTrace or to use most debuggers (e.g., gdb, mdb, lldb), including postmortem debugging. With luck, this behavior might be configurable. To say for sure, you'd either need to look at the V8 source to see what it does, or look at the instructions for compiled JavaScript functions and see if they start with the usual instruction prologue. Some of the information here may help as background: |
|
hey @davepacheco ! - ok so I should update this further - I've mistakenly posted the post-processed stacks (processed with http://npm.im/perf-sym) - don't have the originals but here's another run (also with out delayed tracing) with original stacks - it still has missing info frames in node 8.3 too long for gh comments: |
|
The frames there are consistent with the ustack helper basically not working at all. It may be something small, but there's no silver bullet for this. We basically have to debug the ustack helper from first principles. (As I mention in the blog post, it would probably be easier to fix this in mdb_v8 (or llnode) first.) |
|
I don't have a lot of insight into your profiler. But I assume that it periodically captures the stack and walks it, trying to attribute each frame to functions, either ones compiled by V8 or ones from C++. This does not work with the new bytecode interpreter though. All you get are ticks inside bytecode handlers. V8's own profiler knows how to deal with interpreted frames by extracting the pointer to the bytecode array from the frame. You could teach ustack helper to do the same? |
|
ok so here's the thing - if you run the test script for long enough eventually the missing stacks turn up I guess since we're profiling every ms the JS stacks might be able to sit between the ms ... ? Maybe Turbofans just gotten really really fast at executing the actual JS functions, and the big increase in V8 related frames is just optimization noise thats hogging CPU for a while, initially For normal cases (like a web server) there's actually no (perceptible) effect on this oddity, |
Given:
Node 6.11.2:
Node 8.4.0:
The text was updated successfully, but these errors were encountered: