Electron: Enable renderer process reuse

[rzhao271]

We currently have process reuse disabled in main.js, but considering how the native modules we use are now context-aware, we can start looking more into enabling process reuse.

There are other processes to look into, but for now, I would like to concentrate just on the extensionHost and watcherService. For those, I'm wondering

1. Are the processes killed + restarted during a reload?
2. Are the processes killed + restarted when a user opens a new folder or workspace? I'm currently trying to see if such actions are equivalent to a reload right now, but haven't yet found the code.
3. If yes to 1 and/or 2, can they be set up in a way using IPC such that the main process can send a reset signal during reloads? This way, we can continue using the same child process, and it's just the state of the child process that gets reset.

[rzhao271]

CC @deepak1556

[bpasero]

@rzhao271 anytime a window either gets reloaded, closed or workspace changed within the window, the same code gets triggered to handle this because anyone in the window can participate on this event to either veto it from happening or doing some task (even long running). The events are ILifecycleService.onBeforeShutdown and ILifecycleService.onWillShutdown. The latter is triggered from here:

vscode/src/vs/workbench/services/lifecycle/electron-sandbox/lifecycleService.ts

Line 86 in 94c9ea4

ipcRenderer.on('vscode:onWillUnload', async (event: unknown, reply: { replyChannel: string, reason: ShutdownReason }) => {

I think we can easily use these events to kill processes when the onWillShutdown is fired.

The watcher is actually a IPC Client and it looks like the dispose method will kill the process.

I think the extension host already has code to participate in the shutdown so that extensions can properly get deactivated:

vscode/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts

Line 130 in 94c9ea4

this._toDispose.add(this._lifecycleService.onShutdown(reason => this.terminate()));

A couple of things we have to make sure:

• are there other child processes that the renderer spawns (e.g. search is also a process!)
• are we sure all native modules are either context aware or no longer being used from the renderer (e.g.,only recently I found that the shared process -which is also a renderer process - was still not ready, see spdlog: Loading non-context-aware native module in renderer #120159)
• are there any other implications for process renderer reuse that we need to be thinking about

Would you be interested in providing a PR for this work to help out on this task?

[bpasero]

It looks like windows-process-tree is a dependency that we still drag into the shared process (here) which has not been adopted yet to be context aware iirc. A requirement would be to first make that module context aware unless we can control the process reuse per renderer.

[rzhao271]

are there other child processes that the renderer spawns (e.g. search is also a process!)

Deepak mentioned that I can look for places that call bootstrap-fork, and so I have the following list:

• watcherService
• customEndpointTelemetryService
• ptyHostService
• localProcessExtensionHost
• searchService

The following places use loadURL to open a new window:

• issueMainService
• sharedProcess
• window in windows/electron-main

are we sure all native modules are either context aware or no longer being used from the renderer (e.g.,only recently I found that the shared process -which is also a renderer process - was still not ready, see #120159)

Before doing any optimizations (this issue), we should double-check that all the native modules we use are context-aware. I'll create a separate issue for windows-process-tree.

are there any other implications for process renderer reuse that we need to be thinking about

Deepak provided two scenarios to consider, which are reloading a window, and switching the current workspace. Are there any other cases that could involve a process being reused?

If we implement a reset signal so that instead of killing + relaunching the window, the window state is simply reset, a part we would have to be careful about would be ensuring the old state doesn't leak into the new one.

[deepak1556]

@bpasero in what situations does the shared process get reloaded ? Ignoring the case where we want to restart the process when it crashed.

[bpasero]

Deepak mentioned that I can look for places that call bootstrap-fork

Yes, that is a good way to find out what child processes we spawn from a renderer.

The following places use loadURL to open a new window

Fyi that issueMainService has 2 different windows: the process explorer and the issue reporter

Before doing any optimizations (this issue), we should double-check that all the native modules we use are context-aware

Yes, I would suggest to do a pass over our dependencies of package.json including the optionalDependencies which list specific native modules for Windows only and find the ones which are still being used in renderers.

When I did that last time, I only found the windows-process-tree, while the others where only accessed from either a child process (like file watchers) or the main process.

Deepak provided two scenarios to consider, which are reloading a window, and switching the current workspace

At least for VSCode workbench windows, these 2 are the same. They both go through the same code and will trigger loadURL eventually.

If we implement a reset signal so that instead of killing + relaunching the window, the window state is simply reset, a part we would have to be careful about would be ensuring the old state doesn't leak into the new one.

I do not think that keeping the script context alive is an option currently, simply because we currently have no means of cleaning up all the state on shutdown. So far we get a free cleanup because the context changes everytime we call loadURL. My understanding is that we continue to call loadURL, even when process reuse is enabled, or not?

#35109 is related where we discussed the concept of doing a workspace change without a loadURL call, but there is lots of work involved currently.

@deepak1556

in what situations does the shared process get reloaded

Never. We have no support to reconnect to the shared process currently.

[deepak1556]

So far we get a free cleanup because the context changes everytime we call loadURL. My understanding is that we continue to call loadURL, even when process reuse is enabled, or not?

That is correct and there will be a context change on reload. Based on the lifecycle hooks you have mentioned in #120431 (comment) , they are sufficient to have child processes restart in the process reuse model as well, we don't have to treat the process reuse mode as a different state.