src: use V8 graph heap snapshot API #21741

addaleax · 2018-07-10T22:01:57Z

Addresses a pending V8 deprecation and generally makes our heap snapshot memory reporting much more accurate. I’ll cherry-pick the first commit into its own PR (edit: #21742). Also, since this is somewhat large-ish, I’d recommend per-commit reviewing :)

src: enable more detailed memory tracking

This will enable more detailed heap snapshots based on
a newer V8 API.

This commit itself is not tied to that API and could
be backported.
src: add iteration over all base objects to Environment
Cherry-pick v8/v8@555c811
src: use V8 graph heap snapshot API

Transition to a newer, more flexible API for
heap snapshot creation.

This addresses a currently pending deprecation in the V8 API.

Fixes: Introduce BuildEmbedderGraphCallback #21633
src: make heap snapshot & embedder graph accessible for tests

Add methods that allow inspection of heap snapshots and a JS
version of our own embedder graph.

These can be used in tests and might also prove useful for
ad-hoc debugging. Usage requires --expose-internals and
prints a warning similar to our other modules whose primary
purpose is test support.
test: add heap snapshot tests

Add a number of tests that validate that heap snapshots
contain what we expect them to contain, and cross-check
against a JS version of our own embedder graphs.

/cc @targos @joyeecheung @danbev @nodejs/diagnostics (and maybe @Trott as somebody to look at the last commit?)

nodejs-github-bot · 2018-07-10T22:01:59Z

@addaleax build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/245/pipeline

Trott · 2018-07-10T22:33:19Z

@nodejs/testing on the b5e3c32 commit. LGTM from a quick scan. Will try to look a bit closer later but a review on that from @apapirovski, @BridgeAR, @cjihrig, or @refack might be better than a review from me.

addaleax · 2018-07-10T22:44:39Z

Full CI: ~~https://ci.nodejs.org/job/node-test-pull-request/15792/~~
CI: https://ci.nodejs.org/job/node-test-pull-request/15793/

joyeecheung · 2018-07-11T00:13:45Z

src/heap_utils.cc

@@ -0,0 +1,232 @@
+#include "node_internals.h"


This does not seem to have to be in src? Can we create a directory in test that specifically build this as an addon so we don't need to build it into the binary and use internalBinding to load it?

It does use Environment::BuildEmbedderGraph … would we want to expose that instead?

Edit: Also, I was kinda wondering whether buildEmbedderGraph() could be useful for ad-hoc debugging … even with it printing a warning, I think this might sometimes be useful for inspecting Node?

@addaleax It would be convenient to have helper methods to take a heap dump and get the subgraph of embedder nodes/edges, yes. (Hopefully no one in the user land would attempt to abuse them even with the warning..)

joyeecheung · 2018-07-11T00:39:29Z

lib/internal/test/heap.js

+      let type = types[j];
+      if (Array.isArray(type)) {
+        item[name] = type[raw[i + j]];
+      } else if (type === 'string_or_number') {


name === 'name_or_index' seems more natural? This basically implies that item is an edge.

joyeecheung · 2018-07-11T00:49:58Z

src/cares_wrap.cc

  ChannelWrap* channel;
  ares_socket_t sock;
  uv_poll_t poll_watcher;
+
+  void MemoryInfo(MemoryTracker* tracker) const override;


Shouldn't these subclasses of MemoryRetainer override their MemoryInfoName() as well? If I am reading the code correctly, this prefers using the class names of the target nodes as edge names?

EDIT: the EmbedderGraph API doesn't seem to allow you to specify a name for the edge, even though the class HeapGraphEdge defined in v8-profiler.h has something like that

If I am reading the code correctly, this prefers using the class names of the target nodes as edge names?

Yes… I don’t think it makes much difference in this case, at least as long as we can’t name edges?

joyeecheung · 2018-07-11T01:00:48Z

test/parallel/test-heapdump-fs-promise.js

+  {
+    edges: [
+      { name: 'FSReqPromise' },
+      { name: 'Float64Array' }  // Stat array


If I am reading the code correctly...this means that there will be edges named with class names? Aren't those supposed to be something like property names? (e.g. something like fs_stats_field_array here)

As you edited above, we don’t currently have any ways to name the edges as embedders :/

@addaleax Yeah..I looked into the source a bit, looks like those edges all appear as element edges with auto-incremented indexes (which is kind of odd because then our nodes would appear somewhat like arrays, whereas other internal nodes in V8 usually have internal edges with more meaningful names), it's the validation here that use the target node names for inputs.

I opened a feature request in the upstream: https://bugs.chromium.org/p/v8/issues/detail?id=7938 but until it's sorted out it's still worth landing this with indexed edges IMO. It's better than our current integration anyway.

but until it's sorted out it's still worth landing this with indexed edges IMO

@joyeecheung Can you explain, what does “indexed edges” mean here? i.e. how is it different from what this PR currently does? Or am I missing something? 😄

@addaleax The current EmbedderGraph API will create edges with type kElement and with indexes that are automatically incremented (based on the count of edges of the from node). The internal V8 edges, for example, the ones pointing to shared function info or context nodes from JS functions, have type kInternal and corresponding string names. That's why those references show up in the DevTools as gray and will have proper names displayed (otherwise you may see a function has a reference named with a number to a shared function info node, instead of a reference named shared, which is odd because you rarely see a function with a number-keyed property and you couldn't tell if it's added by you in the JS land).

@addaleax Yeah, if I understand correctly the snapshots generated with the current approach will show up with number indexed references from the embedder nodes to other nodes (e.g. it looks as if FSREQPROMISE[1] = Float64Array(...) instead of FSREQPROMISE.stats_field_array = Float64Array(...), the members will have their names overridden from Float64Array to stats_field_array), which would look a bit confusing but still it's better than no references tracked in the snapshots at all.

I opened https://chromium-review.googlesource.com/c/v8/v8/+/926362 BTW

I opened https://chromium-review.googlesource.com/c/v8/v8/+/926362 BTW

@joyeecheung Tbh, I don’t really understand the semantics of NamePrefix either. :/

@addaleax Ooops, wrong link: https://chromium-review.googlesource.com/c/v8/v8/+/1133299

By the way this is what I meant by "indexed edges", which are also created by the deprecated RetainedObjectInfo. Making those numbers human-readable names would help users navigate in the DevTools.

Okay, yeah, makes sense – not the end of the world but would definitely be very nice to have.

addaleax · 2018-07-12T10:51:56Z

@joyeecheung Should we wait for your CL to be merged, and then update this? I think that makes sense at this point?

joyeecheung · 2018-07-12T11:27:59Z

test/common/heap.js

+      if (expectedNode.edges) {
+        for (const expectedEdge of expectedNode.edges) {
+          const check = typeof expectedEdge === 'function' ?
+            expectedEdge : (node) => node.name === expectedEdge.name;


It's a bit confusing to name that expectedEdge.name since the name is actually from the target node and not the edge itself. Can we change the format of expected a bit to be clearer? I think referring to those as children and child would be enough?

Yup, sounds good. Done!

While addressing this, it occurred to me that expectedChild may or may not be a sensible variable name to use (because of the real-world usage of that term), but I’ll leave it that way until somebody has something better. :)

joyeecheung · 2018-07-12T11:33:17Z

Should we wait for your CL to be merged, and then update this? I think that makes sense at this point?

@addaleax I don't think we need to wait until the CL is merged, since currently the snapshot generated from Node.js have indexed edges anyway and this is still an improvement since it tracks more stuff and gets rid of usage of a deprecated API. The naming of the edges can be left as a future exercise.

joyeecheung · 2018-07-12T11:47:27Z

src/memory_tracker-inl.h

+    }
+  }
+
+  const char* Name() override { return name_.c_str(); }


We may want to override NamePrefix() as well? Like using Node / so our nodes would appear with names Node / Zlib and they would be more distinguishable that way (the node names are more like class names instead of reference names). V8 tend to use system / as a prefix for internal nodes like contexts and Chromium sometimes use Window / (although they seem to be just prepending the prefixes manually instead of using this API).

Sounds good to me, done! :)

addaleax · 2018-07-12T12:14:31Z

Should we wait for your CL to be merged, and then update this? I think that makes sense at this point?

@addaleax I don't think we need to wait until the CL is merged, since currently the snapshot generated from Node.js have indexed edges anyway and this is still an improvement since it tracks more stuff and gets rid of usage of a deprecated API. The naming of the edges can be left as a future exercise.

@joyeecheung I’m asking because we do need to adjust src/heap_utils.cc when your CL lands, and in particular V8 will have to update their copy of Node to account for it. It’s trivial to work around the method signature change, but, you know, might be easier that way? Otherwise I completely agree. :)

And in any case, thanks for working through this with me! 🙂

(Edit: Just remembering, your CL is ABI-breaking. We could ignore that but maybe we shouldn’t.)

This patch adds a variant of EmbedderGraph::AddEdge() which allows the embedder to specify the name of an edge. The edges added without name are element edges with auto-incremented indexes while the edges added with names will be internal edges with the specified names for more meaningful output in the heap snapshot. Refs: nodejs/node#21741 Bug: v8:7938 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8feefa2cf6911743e24b3b2024e0e849b0c65cd3 Reviewed-on: https://chromium-review.googlesource.com/1133299 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#54412}

joyeecheung

LGTM with a nit. Thanks for working on this!

joyeecheung · 2018-07-12T22:02:29Z

test/common/README.md

+```js
+validateSnapshotNodes('TLSWRAP', [
+  {
+    edges: [


This is now children

Thanks, done!

joyeecheung · 2018-07-12T22:09:13Z

@addaleax Regarding the ABI breakage: I think if we want stay on the safe side, we'd better cherry-pick the CL and use the new signature in another PR and mark it as dont-land-on-v10.x? I couldn't think of a way to avoid the breakage given how EmbedderGraph::Node is designed :(

refack · 2018-07-13T16:45:44Z

test/common/README.md

@@ -538,6 +539,41 @@ Returns the result of
 Returns the result of
 `fs.readFileSync(path.join(fixtures.fixturesDir, 'keys', arg), 'enc')`.

+## Heap dump cheker module
+
+This provides utilities for checking the validity of heap dumps.


Could you add a comment that this requires --expose-internals

refack · 2018-07-13T16:49:32Z

test/common/heap.js

+'use strict';
+const assert = require('assert');
+const util = require('util');
+const { createJSHeapDump, buildEmbedderGraph } = require('internal/test/heap');


Maybe add:

try { require.resolve('internal/test/heap'); } catch (e) { console.log("using `test/common/heap.js` requires `--expose-internals`"); throw e; }

addaleax · 2018-07-13T16:54:12Z

@refack Thanks for the review, done in 175b272426a7b9e5fe228316adb0ade613aab997!

refack · 2018-07-13T16:54:14Z

👍 seems like a very helpful tool.

Regarding the ABI breakage

Doesn't that necessitate semver-major?

addaleax · 2018-07-13T17:00:08Z

@refack The ABI breakage was referring to v8/v8@6ee8345, and we decided against including it for that reason :)

Original commit message: [api] Switch from `SetBuildEmbedderGraphCallback` to `AddBuildEmbedderGraphCallback` `SetBuildEmbedderGraphCallback`, unlike `SetWrapperClassInfoProvider`, assumes a monolithic embedder that can provide all necessary information. That is not the case for e.g. Node.js, which can e.g. provide multiple Node.js instances per V8 Isolate, as well as native addons that may allocate resources on their own. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ib53dfde82416dd69934b08623e27d674a483ac2d Reviewed-on: https://chromium-review.googlesource.com/1082441 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#53545} Refs: v8/v8@555c811 PR-URL: nodejs#21741 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>

Original commit message: [api] Switch from `SetBuildEmbedderGraphCallback` to `AddBuildEmbedderGraphCallback` `SetBuildEmbedderGraphCallback`, unlike `SetWrapperClassInfoProvider`, assumes a monolithic embedder that can provide all necessary information. That is not the case for e.g. Node.js, which can e.g. provide multiple Node.js instances per V8 Isolate, as well as native addons that may allocate resources on their own. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ib53dfde82416dd69934b08623e27d674a483ac2d Reviewed-on: https://chromium-review.googlesource.com/1082441 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#53545} Refs: v8/v8@555c811 Backport-PR-URL: #21668 PR-URL: #21741 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>

Original commit message: [heap-profiler] Allow embedder to specify edge names This patch adds a variant of EmbedderGraph::AddEdge() which allows the embedder to specify the name of an edge. The edges added without name are element edges with auto-incremented indexes while the edges added with names will be internal edges with the specified names for more meaningful output in the heap snapshot. Refs: nodejs#21741 Bug: v8:7938 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8feefa2cf6911743e24b3b2024e0e849b0c65cd3 Reviewed-on: https://chromium-review.googlesource.com/1133299 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#54412} Refs: v8/v8@6ee8345

Original commit message: [heap-profiler] Allow embedder to specify edge names This patch adds a variant of EmbedderGraph::AddEdge() which allows the embedder to specify the name of an edge. The edges added without name are element edges with auto-incremented indexes while the edges added with names will be internal edges with the specified names for more meaningful output in the heap snapshot. Refs: #21741 Bug: v8:7938 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8feefa2cf6911743e24b3b2024e0e849b0c65cd3 Reviewed-on: https://chromium-review.googlesource.com/1133299 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#54412} Refs: v8/v8@6ee8345 PR-URL: #22106 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

We have migrated from the deprecated RetainedObjectInfo API to the new EmbedderGraph API, so there is no need to take care of wrapper class ids anymore since they are dedicated to the deprecated API (the new API uses a graph instead of ids to retrieve info about nodes). PR-URL: #22975 Refs: #21741 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Jul 10, 2018

addaleax mentioned this pull request Jul 10, 2018

src: enable more detailed memory tracking #21742

Closed

2 tasks

addaleax added the dont-land-on-v8.x label Jul 10, 2018

jasnell approved these changes Jul 10, 2018

View reviewed changes

addaleax force-pushed the heap branch from b5e3c32 to c197f31 Compare July 10, 2018 23:00

joyeecheung reviewed Jul 11, 2018

View reviewed changes

addaleax force-pushed the heap branch 2 times, most recently from 044d423 to 01f050d Compare July 11, 2018 16:24

joyeecheung reviewed Jul 12, 2018

View reviewed changes

addaleax force-pushed the heap branch from 01f050d to b767313 Compare July 12, 2018 12:14

joyeecheung approved these changes Jul 12, 2018

View reviewed changes

addaleax force-pushed the heap branch 2 times, most recently from 8a0cf5c to e354714 Compare July 13, 2018 13:00

refack approved these changes Jul 13, 2018

View reviewed changes

targos mentioned this pull request Jul 17, 2018

v10.7.0 proposal #21851

Merged

rvagg mentioned this pull request Aug 13, 2018

Release proposal: v10.9.0 #22295

Merged

joyeecheung mentioned this pull request Sep 20, 2018

src: remove calls to SetWrapperClassId() #22975

Closed

2 tasks

src: use V8 graph heap snapshot API #21741

src: use V8 graph heap snapshot API #21741

Conversation

addaleax commented Jul 10, 2018 • edited

nodejs-github-bot commented Jul 10, 2018

Trott commented Jul 10, 2018

addaleax commented Jul 10, 2018 • edited

Choose a reason for hiding this comment

addaleax Jul 11, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung Jul 11, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung Jul 11, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung Jul 11, 2018 • edited

Choose a reason for hiding this comment

joyeecheung Jul 11, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung Jul 11, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Jul 12, 2018

joyeecheung Jul 12, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung commented Jul 12, 2018 • edited

joyeecheung Jul 12, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Jul 12, 2018 • edited

joyeecheung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung commented Jul 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Jul 13, 2018

refack commented Jul 13, 2018

addaleax commented Jul 13, 2018

addaleax commented Jul 10, 2018 •

edited

addaleax commented Jul 10, 2018 •

edited

addaleax Jul 11, 2018 •

edited

joyeecheung Jul 11, 2018 •

edited

joyeecheung Jul 11, 2018 •

edited

joyeecheung Jul 11, 2018 •

edited

joyeecheung Jul 11, 2018 •

edited

joyeecheung Jul 11, 2018 •

edited

joyeecheung Jul 12, 2018 •

edited

joyeecheung commented Jul 12, 2018 •

edited

joyeecheung Jul 12, 2018 •

edited

addaleax commented Jul 12, 2018 •

edited