Apparently so:

google/WebFundamentals#6868

If so, can you suggest an alternate source for this view?

https://github.com/thlorenz/v8-perf/blob/master/memory-profiling.md#dominators-view

Trying to gain information here WRT to a bug I filed with lldb originally.

Basically I just want to make sure I understand the problem correctly in order to file a helpful bug report with the v8 team. I created a step by step guide to help reproduce the problem.

The latest from the mentioned bug report is that some information seems to be missing from the DWARF that is generated by v8 (I wrote the memory indicated to contain the JIT info to disk to be able to dwarfdump it).

Quoting Greg Clayton from the lldb team:

There is just a __TEXT.__text segment and a __TEXT.eh_frame section:

% dwarfdump -R /Volumes/work/gclayton/Downloads/jit.o 
----------------------------------------------------------------------
 File: /Volumes/work/gclayton/Downloads/jit.o (x86_64)
----------------------------------------------------------------------
Header
magic:      0xfeedfacf
cputype:    0x01000007
cpusubtype: 0x00000003
filetype:   0x00000001
ncmds:      0x00000001
sizeofcmds: 0x000000e8
flags:      0x00000000


Segments
Segment Name     vmaddr           vmsize           fileoff          filesize         maxprot  initprot nsects   flags
---------------- ---------------- ---------------- ---------------- ---------------- -------- -------- -------- --------
                 000008c6762a0760 00000000000003d4 0000000000000108 0000000000000068 00000007 00000007 00000002 00000000

Sections
Section Name     Segment Name     addr             size             offset   align    reloff   nreloc   flags    reserv1  reserv2  reserv3  size     size %
---------------- ---------------- ---------------- ---------------- -------- -------- -------- -------- -------- -------- -------- -------- ======== ======
__text           __TEXT           000008c6762a0760 00000000000003d4 00000000 00000005 00000000 00000000 80000400 00000000 00000000 cdcdcdcd  980       nan%
__eh_frame       __TEXT           0000000000000000 0000000000000068 00000108 00000003 00000000 00000000 00000000 00000000 00000000 cdcdcdcd  104       nan%

You might need to tell the JIT memory manager to load the DWARF somehow. It doesn't seem like the DWARF is making it into the final memory mach-o where it probably is for ELF.

@mraleph gave some pointers on twitter

if it does - debug section should be called __debug_info not .debug_info

In the above dwarfdump I see neither of those mentioned debug sections. So seems like it's just missing completely?

Greg Clayton from the lldb team suggested:

get the JIT team to help you to be able to get a the DWARF into the __DWARF segment

indicating that a huge portion of the information is missing.

I personally just started diving into the land of dwarfs, elfs and machos so any help to clarify things or pointers where to look, what to read up on, etc. to figure this out is greatly appreciated.

I also have a feeling that @indutny may know a lot more about this than I do at this point ;)

blogs/tutorials

Mainly related to analyzing memory heap dumps (i.e. not time line) since that is the only memory related data that can be gathered from a Node.js app (afaik).

Unfortunately most of these are out of date :( but still useful.

• chrome-docs memory profiling
  • related demos including more resources
• chrome-docs Memory Analysis 101 overlaps with chrome-docs memory profiling
• chrome-docs heap profiling overlaps with chrome-docs memory profiling
• Chasing Leaks With The Chrome DevTools Heap Profiler Views
  • heap profiler in chrome dev tools
  • performance-optimisation-with-timeline-profiles time line data cannot be pulled out of a Node.js app currently, therfore skipping this for now
• timeline and heap profiler
• chromium blog
• Easing JavaScript Memory Profiling In Chrome DevTools
• Effectively Managing Memory at Gmail scale
• javascript memory management masterclass
• fixing memory leaks in drupal's editor
• writing fast memory efficient javascript
• imgur avoiding a memory leak situation in JS

videos

• The Breakpoint Ep. 8: Memory Profiling with Chrome DevTools
• Google I/O 2013 - A Trip Down Memory Lane with Gmail and DevTools

slides

• Finding and debugging memory leaks in JavaScript with Chrome DevTools
• eliminating memory leaks in Gmail

goal

I'm trying to gather resources and tools that make it easier to profile Node.js apps ideally by integrating with Chrome Dev tools and chrome://tracing.

what I found so far

Documentation of tools to analyse the data has been started here but the integration part with Node.js is still missing.

I tried to gather some free and open source tools that try to make this easier and would love to get some feedback and/or further tool suggestions. Pointers to any resources that document anything related are also greatly appreciated.

tools

webkit-devtools-agent looks very promising, but doesn't show flamegraphs and has no time line support.

techniques

With a version of node that has a --log-timer-events as part of v8-options, run the app in profiling mode and load the resulting v8.log into Chrome at chrome://tracing.

Check for supported flag:

➝  node --v8-options | grep log_timer_events
  --log_timer_events (Time events including external callbacks.)

Profile app to generate v8.log including GC events.

node --prof --track_gc_object_stats --trace_gc_verbose --log_timer_events app.js

Loading into chrome://tracing will yield a flame chart similar to the below:

A detailed explanation is outlined in creating v8 profiling timeline plots although some of the information seems a bit outdated.

what I'm interested in

The idea is to find a way to use the built in Chrome tools to profile Node.js apps the same way as is currently possible
for JavaScript apps running in the browser.

Interesting metrics to gather:

• CPU profile including flamecharts - what's described here but for Node.js apps
• Heap profile, snapshots and diffs - what's described here but for Node.js apps
• GC events and timeline

Additionally integration with chrome://tracing by passing flags like --log_timer_events are of interest.

Both, CLI and GUI support would be nice to have as well as real-time and historical data.

Can be useful.
http://upstream.rosalinux.ru/versions/v8.html

Thanks for the project.

Creating

alias ngc='/Users/thlorenz/dev/js/node/out/Release/node --prof --track_gc_object_stats --trace_gc_verbose --log_timer_events'

Interpreting

How to interpret and more at same site.

• trevor norris perf training notes

The list at https://github.com/thlorenz/v8-perf/blob/master/data-types.md#fast-elements implies that fast elements have the characteristic of being smaller than 64k. But there is no such restriction, a single array or object can be any size (before causing oom error) and still have fast elements.

The considerations list at https://github.com/thlorenz/v8-perf/blob/master/data-types.md#considerations-1 says not to pre-allocate arrays with more than 64k elements, but this limit has always been 99999 and has never been changed (except when it was temporarily changed to 94999).

Resources

• JavaScript and V8 TurboFan by Ariya Hidayat.
• V8, Advanced JavaScript, & the Next Performance Frontier (Google I/O '17)
• Erik Meijer and Lars Bak: Inside V8 - A Javascript Virtual Machine
• turbolizer: IRHydra for Turbofan?

Turbofan differences to Crankshaft

• convert the JS to an AST because of the new sea of nodes approach for code analysis

@mraleph I thought about what the best way would be to enable you to comment on/correct/add to the material here.

So I squashed all commits into one in order to facilitate a line by line discussion in the the diff.
This way we can go back and forth discussing the details if we want.

However I also created a disc-one branch and gave you commit access to the repo, so you can quickly jot down in that branch whatever needs to be added/corrected. I'll sort it out then to pull it into master.

Let me know if this setup works for you or if you prefer another way to contribute. I wanna make this as easy and efficient as possible.

I very much appreciate you taking the time to contribute to help get this information into a good state :)

• Node.js remote debugging client for Firefox

From discussion on irc -- we need links:

• for 5.1: The value of Number.MAX_VALUE is the largest positive finite value of the Number type, which is approximately 1.7976931348623157 × 10^308.
• well, 6 is a little different: The value of Number.MAX_SAFE_INTEGER is 9007199254740991 (2^53−1)
• so here's the thing, JS only supports IEEE-754 FP... that does not "fit" an int64
• some early work tootallnate did wrt core
  follows: "if it fits use number, otherwise use string" pattern