feat: memory profiling

[seemk]

tldr

• Use v8::HeapProfiler to periodically capture an allocation profile along with the samples.
• The allocation samples returned from v8 are "live memory", so we have to keep track which samples were added.
• Samples have a node_id which is its node ID in the call graph. To generate a stack trace this node needs to be found from the allocation profile.
• For the finding the whole allocation profile graph is converted to a more convenient format, so when we have a node id, we can do a dictionary lookup and reconstruct the path to a root callgraph node which maps nicely to the pprof location array. The conversion requires generating the whole graph. There is room for improvement here (e.g. caching the node graph and only regenerate it when we find an unknown node_id from the samples), but at the moment it seems to be fast enough.

⚠️ Trace and span ID correlation can't be done because V8 does not provide any timing information for the samples.

Misc

• Removed obsolete Node.js versions (<12) from prebuild:os script

[codecov-commenter]

Codecov Report

Merging #524 (d9a517a) into main (96a308a) will decrease coverage by 1.70%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main     #524      +/-   ##
==========================================
- Coverage   88.94%   87.24%   -1.71%     
==========================================
  Files          27       27              
  Lines         914      972      +58     
  Branches      204      210       +6     
==========================================
+ Hits          813      848      +35     
- Misses        101      124      +23     

Impacted Files	Coverage Δ
src/profiling/DebugExporter.ts	18.75% <0.00%> (-11.25%)	⬇️
src/profiling/types.ts	100.00% <ø> (ø)
src/profiling/OTLPProfilingExporter.ts	36.06% <10.00%> (-12.78%)	⬇️
src/profiling/index.ts	90.00% <100.00%> (+2.34%)	⬆️
src/profiling/utils.ts	90.81% <100.00%> (+1.65%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[aurbiztondo-splunk]

Suggestion: Memory profiling is disabled by default. You can enable it via the memoryProfilingEnabled flag.

[seemk]

Thanks! Perhaps you already know, but GitHub lets you add suggestions directly to the comment via a suggest code block, so the author can press a button to bring the change in, for example:

Suggested change

	Memory profiling is disabled by default, it can be enabled via the `memoryProfilingEnabled` flag.
	Memory profiling is disabled by default. You can enable it via the `memoryProfilingEnabled` flag.

[aurbiztondo-splunk]

Suggestion: You can tune V8 heap profiler's parameters using the memoryProfilingOptions configuration field:

[rauno56]

Mainly curious questions.

[rauno56]

Are the node id's unique across the lifetime of the program? I ask to suss out why use object instead of an array where the keys are integers already - saves a conversion and perhaps some (type) errors(even though arr[2] === arr['2']).

[seemk]

Node ID is an incrementing counter. No idea how large it gets and how many gaps will exist. Just used a denser form 🤷‍♂️

[rauno56]

const arr = [];
array[5] = "hello";
array[10] = "world";

Makes a "holey" array, which is equivalent in terms of the density. I assume calling the same API from the native side behaves the same.

[seemk]

Tested it and it actually turns to DICTIONARY_ELEMENTS type even with a small app as the node IDs get large, thus it's basically the same as using an object 🤔 And for some reason the average read speed was actually faster when using an object (no idea why) while the write speeds stayed the same.