Open Bug 1384285 Opened 7 years ago Updated 2 years ago

make service workers use a separate ScriptLoader that avoids main thread

Categories

(Core :: DOM: Service Workers, enhancement, P2)

Product:
Core
Component:
DOM: Service Workers
Type:
enhancement

Tracking

()

People

(Reporter: bkelly, Unassigned)

References

(Blocks 1 open bug)

Details

Today we have a single ScriptLoader.cpp in dom/workers that all worker code uses. There are two different major paths through this code, though: 1. nsIChannel based loads for dedicated and shared workers. 2. Cache API based loads for service workers. Path (1) requires touching the main thread a number of times. Path (2), however, could avoid many main thread operations. The Cache API is completely usable from worker thread without touching the main thread. The only code that might require a main thread touch is stuff like nsIPrincipal. In this interest of speeding of service worker load time we should consider splitting its ScriptLoader out so that it no longer requires main thread everywhere. This might also make it easier to understand the code since the Cache API is very different from nsIChannel. The main downside is that we would have to duplicate some things like error handling, importScripts(), modules, etc. Maybe those could be factored out so they can be included in either style script loader. This is probably a relatively large task, but would like show some good gains in our SW performance telemetry.
Priority: -- → P2
It now looks like this will be needed after all. Previously we wanted to make a separate worker process, but given spectre style attacks we need to try to isolate content origins in separate processes if we can. That means no worker process shared by all origins. Instead we will want to run the service worker in a content process already containing the origin. Since that process may have a busy main thread this bug would be a more significant performance win.

:perry, didn't our process model for service workers change now with e10s ? Is this still an issue?

Flags: needinfo?(perry)

This bug is still relevant. (Driveby because of some additional All-Hands discussion.) All worker script loads still currently happen on/via bounces to the main thread in a ScriptLoader.cpp. This loader, dom/workers/ScriptLoader.cpp is worker-specific and distinct from the dom/script/ScriptLoader.cpp implementation which supports ES Modules.

The main changes to note in this area are that:

  • nsIChannel/http channel can deliver data off the main thread.
  • AsyncOpen for channels will soon (March-April targeted) be able to open channels off the main thread, allowing us to bypass most/all needs to touch the main thread.
  • We potentially need a (Main)WorkerChannel to be analogous to DocumentChannel for COOP/COEP process-selection reasons where we really want to inspect and assert about the header in the parent rather than in the child.

One relevant thing discusses at the all-hand is:

  • Could we attempt to unfork the worker scriptloader further if AsyncOpen means it can largely run on any thread and if we can abstract away the Cache API aspects into a channel like ServiceWorkerChannel. ServiceWorkerChannel could be a Cache API-specific channel that redirects to a real http channel during install.

Right, the process model did change but it didn't' affect this.

Flags: needinfo?(perry)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.