This is Chromium's implementation of service workers. See the Service Worker specification.
Service worker storage consists of the following.
Code pointers include ServiceWorkerDatabase and ServiceWorkerStorage.
The related Cache Storage API uses a disk_cache instance using the “simple” implementation, located at ${DIR_USER_DATA}/Service Worker/CacheStorage. This location was chosen because the Cache Storage API is currently defined in the Service Worker specification, but it can be used independently of service workers.
For incognito windows, everything is in-memory.
Service workers storage lasts indefinitely, i.e, there is no periodic deletion of old but still installed service workers. Installed service workers are only evicted by the Quota Manager (or user action). The Quota Manager controls several web platform APIs, including sandboxed filesystem, WebSQL, appcache, IndexedDB, cache storage, service worker (registration and scripts), and background fetch.
The Quota Manager starts eviction when one of the following conditions is true (as of August 2018):
When eviction starts, origins are purged on an LRU basis until the triggering condition no longer applies. Purging an origin deletes its storage completely.
Note that Quota Manager eviction is independent of HTTP cache eviction. The HTTP cache is typically much smaller than the storage under the control of the Quota Manager, and it likely uses a simple non-origin-based LRU algorithm.
Blink has a UseCounter mechanism intended to measure the percentage of page loads on the web that used a given feature. Service workers complicate this measurement because a feature use in a service worker potentially affects many page loads, including ones in the future.
Therefore, service workers integrate with the UseCounter mechanism as follows:
For more details and rationale, see Design of UseCounter for workers and crbug 376039.
Code pointers include: