Description
We need to figure out the proper relationship between these entities in order to diagram it (see #3863), but also to understand what we're building.
Here's my high-level sketch based on a conversation with @mystor a while back (mistakes mine):
A user agent holds shared/service worker agent cluster map, for agent clusters containing a shared worker agent or a service worker agent. (This is already shared understanding I think, but restating for clarity.)
A user agent holds a session set, consisting of zero or more sessions. (A session is roughly equivalent to what we call "session history" in HTML today, shortened here for brevity and distinction.)
A session consists of zero or more session entries. A session entry is effectively the state of a "session history entry", but also holds a reference to a top-level browsing context (as that can change within a session due to COOP).
A top-level browsing context is part of a browsing context group. (As defined today, except that a user agent no longer holds a browsing context group directly.)
A browsing context group holds an agent cluster map. (As sketched in #4361 and currently being formalized in #4617.) I would suggest we make this a weak map (not in the JavaScript sense) as managing the teardown of these agent clusters explicitly is tricky, e.g., it would make #4390 even more complicated as we'd have to handle the case of a "remote WindowProxy" trying to message an agent cluster that has disappeared explicitly as well, whereas otherwise we could pretend there's a smart cross-process GC that keeps it alive. And also, I don't think we really want to start reference count all the callers and such (or do a search for all usage whenever there's a change).
XXX: It's not clear that all worklets should have their own agent, e.g. audio worklets need to be part of an agent cluster that also holds a similar-origin window agent.
The key "changes" are that sessions are at the top as they need to manage transitions between top-level browsing contexts (what exactly ends up being observable here is up for debate, but there's ambition for "bfcache" at least). And since the scope of a session is a top-level browsing context, browsing context groups become a sideshow. And then also more clearly acknowledging that while a browsing context group keeps track of agent clusters, it's not responsible for collecting them. (This also helps with @dtapuska's scenario where each browsing context might get its own agent cluster. It'd be bad standard writing if we didn't allow those to be collected before all top-level browsing contexts in the browsing context group were closed.)
Thoughts on this appreciated!