Sandbox: move v8-inspect-profiler out of renderer

[bpasero]

Looking through the list of node modules we still depend on from the renderer I came across v8-inspect-profiler. My understanding is that we use this native module for:

• profiling VSCode itself (but this seems to be triggered from the main process so it seems fine?)
• profiling extensions (inside the extension host)
• saving profiles to disk (from renderer)

I think the first two usages are fine and will stay supported even in sandbox mode where the extension host will still be allowed to access node. My question is wether we can move the dependency from the renderer out into the extension host possibly?

The relevant location in code seems to be:

vscode/src/vs/workbench/contrib/extensions/electron-browser/extensionsSlowActions.ts

Line 133 in 2046205

const profiler = await import('v8-inspect-profiler');

and

vscode/src/vs/workbench/contrib/extensions/electron-browser/extensionsSlowActions.ts

Line 177 in 2046205

const profiler = await import('v8-inspect-profiler');

and

vscode/src/vs/workbench/contrib/extensions/electron-browser/runtimeExtensionsEditor.ts

Line 694 in 2046205

const profiler = await import('v8-inspect-profiler');

If we cannot move this into the extension host, then I can possibly expose a new method from the native host service to do so via IPC.

[jrieken]

dependency from the renderer out into the extension host possibly?

Not possible because this is needed when the extension host appears dead, e.g it's not accepting any requests and not sending any responses anymore.

[bpasero]

Got it. It seems the methods needed are rewriteAbsolutePaths and writeProfile but it seems in the end we just want to write a profile to disk so we could probably have 1 method for this on the main side. For that, the profile needs to be serializable via IPC though, but I think that is already happening from the extension host.

[bpasero]

Discussed with Jo:

• for this to land it would be easier if the final extension host architecture is in place (with a backend process)
• then we can revisit how profiling should work when triggered from the workbench through actions or extensions editor or even automated
• also interesting would be to support remote extension host profiling

For our first version of a sandboxed renderer it is tolerable to have ext-host profiling disabled since it is for diagnosing perf issues and not critical for selfhosting.

[deepak1556]

There is now native sampling profiler api available starting with chrome 94 which can also serve as an alternative for running in sandboxed environments.

https://blog.chromium.org/2021/08/chrome-94-beta-webcodecs-webgpu.html
https://wicg.github.io/js-self-profiling/