feat: add process.getBlinkMemoryInfo()

[miniak]

Description of Change

Expose blink memory information provided by https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/heap/process_heap.h

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added process.getBlinkMemoryInfo().

[MarshallOfSound]

Few questions before my plane takes off.

How does this line up with the existing process.getMemoryInfo API?

Can we / should we combine them?

How does the unified heap (shipped in 73 iirc) impact these APIs?

And then can we strongly document the answers to the above questions so when users look at these APIs they know what the values mean / represent

[miniak]

@MarshallOfSound actually that blink API I've used seems to be private. I am getting this error:

ERROR at //electron/atom/common/api/electron_bindings.cc:32:11: Can't include this header from here.
#include "third_party/blink/renderer/platform/heap/process_heap.h"
          ^------------------------------------------------------
The target:
  //electron:electron_lib
is including a file from the target:
  //third_party/blink/renderer/platform/heap:heap

It's usually best to depend directly on the destination target.
In some cases, the destination target is considered a subcomponent
of an intermediate target. In this case, the intermediate target
should depend publicly on the destination to forward the ability
to include headers.

Dependency chain (there may also be others):
  //electron:electron_lib -->
  //third_party/blink/public:blink --[private]-->
  //third_party/blink/renderer/platform:platform -->
  //third_party/blink/renderer/platform/heap:heap

trying to add the dependency results in another error:

ERROR at //electron/BUILD.gn:363:1: Dependency not allowed.
static_library("electron_lib") {
^-------------------------------
The item //electron:electron_lib
can not depend on //third_party/blink/renderer/platform/heap:heap
because it is not in //third_party/blink/renderer/platform/heap:heap's visibility list: [
  //third_party/blink/renderer/platform:platform
]

[miniak]

hmm, // nogncheck suppresses the error

[MarshallOfSound]

@miniak Any update on the above questions?

[ahujasusheel]

@MarshallOfSound

Few questions before my plane takes off.

How does this line up with the existing process.getMemoryInfo API?

I assume the question is on getProcessMemoryInfo. Since getProcessMemoryInfo gives back the memory info in terms of resident set, private and shared bytes, and since these are used to measure how any process is behaving and known measures of process with respect to OS is slightly different from getBlinkMemoryInfo, which gives an idea of how much memory is taken by blink_gc/oilpan which is specific to chromium and electron.

Can we / should we combine them?

We should not combine them because these are used for debugging different issue. Blink memory info will be used mostly to debug rendering/dom related memory issues.

How does the unified heap (shipped in 73 iirc) impact these APIs?

There should not be any difference in terms of what these api's return for blink gc allocations, before and after unified heap.

And then can we strongly document the answers to the above questions so when users look at these APIs they know what the values mean / represent

Sure, we should do this.

[miniak]

@MarshallOfSound can you please check @ahujasusheel's comment. I was not formatted properly and therefore appeared as spam. I've fixed it.

[MarshallOfSound]

@miniak Yeah I'm just waiting on the output of

We are investigating this.

and

And then can we strongly document the answers to the above questions so when users look at these

Sure, we should do this.

Docs + Unified Heap impact

[miniak]

@MarshallOfSound will talk to my colleagues about those and hopefully update the PR soon

[miniak]

@MarshallOfSound I've updated the docs. Is it sufficient or do we need even more details? @ahujasusheel updated his reply, it should answer all the questions now (Unified Heap impact + no more "We are investigating this")

[miniak]

@MarshallOfSound are you ok with the current state of the PR?

[alexeykuzmin]

@nornagon
Is it ok to use nogncheck to suppress gn error Can't include this header from here.?

[miniak]

we do it here as well
#include "third_party/blink/renderer/platform/weborigin/scheme_registry.h" // nogncheck

[miniak]

@alexeykuzmin are we going to merge this one or not?

[release-clerk]

Release Notes Persisted

Added process.getBlinkMemoryInfo().