doc: move perf tools and APIs to Tier 3

[mmarchini]

V8 CodeEventHandler, Linux perf and the --interpreted-frames-native-stack flag satisfies our Diagnostics Support requirements for Tier 3. V8 CodeEventHandler is tested as part of our V8 CI, and Linux perf / --interpreted-frames-native-stack are tested by test/v8-updates/test-linux-perf.js.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• documentation is changed or added
• commit message follows commit guidelines

cc @nodejs/diagnostics

[nodejs-github-bot]

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

[mhdawson]

I think we could leave the target tier in the tiers. For example if its in tier 3 it might still have a target or 1

[mmarchini]

Update:

• Include --prof, --prof-process and V8 CpuProfiler as discussed in Bump node-clinic to tier 3 diagnostics#234
• Restore the Target Tier columns
• Set Target Tier of V8 CodeEventHandler, --interpreted-frames-native-stack and Linux perf to 2.

[mmarchini]

CI Lite: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/1029/

[BridgeAR]

How come these flags are separate to the V8 CPU profiler? And the current tests do not properly test everything in depth, right?

[mmarchini]

How come these flags are separate to the V8 CPU profiler?

Because they are separate things: V8 CpuProfiler is a C++ API officially supported by V8 which can also be used through the inspector protocol. --prof is a flag not officially supported by V8.

And the current tests do not properly test everything in depth, right?

Right. That's why we're moving them to Tier 3 and not 2/1.

[BridgeAR]

Should we maybe say it's also partial in that case until we have more tests in place?

[joyeecheung]

It still feels strange to me that we put V8 stuff in our support tiers, but as long as they don't block our releases, LGTM

[mmarchini]

IMO we should either support those things - preferably blocking, at least on LTS - or throw warnings to show users these features are unstable and can break at any time. Otherwise users might trust these things are stable and they might get stuck in a EOL version because they are relying heavily in some unsupported features.

[joyeecheung]

Otherwise users might trust these things are stable and they might get stuck in a EOL version because they are relying heavily in some unsupported features.

I think this should only apply to LTS releases - it doesn't make too much sense to block a odd-number release with that reasoning, does it? I don't think it would get in our way if it only applies to LTS, since we try not to update V8 in LTS anyway.

[mmarchini]

I think this should only apply to LTS releases - it doesn't make too much sense to block a odd-number release with that reasoning, does it? I don't think it would get in our way if it only applies to LTS, since we try not to update V8 in LTS anyway.

Yeah, I guess. Having these tools stable inside an LTS is the least we can do.

I'm still kinda worried though. All profiling and heap analysis solutions we have on Node.js today are actually V8 APIs and flags. Maybe core should expose stable APIs for these use cases, and we can keep them working even if V8 changes their APIs entirely (as suggested in nodejs/abi-stable-node#296)?

[Flarna]

Another topic is test coverage and test quality. Not sure if V8 team spends the same energy into testing diagnostic tools as in the productive features - it would be valid to prioritize production features.

Besides that the use cases/requirements in node differ from browser in some aspects. A memleak or busy loop for diagnostic tools running in browser is most likely not that critical as in a server application as the impact is limited.

[mhdawson]

LGTM

[mmarchini]

CI Lite before landing: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/1084/ ✅

[mmarchini]

Landed in fa14503