Define GC for workers in more detail

[annevk]

Currently a worker tracks MessagePort objects. It should probably track BroadcastChannel objects too, otherwise you can observe GC to some approximation.

cc @smaug---- @wanderview

[smaug----]

I'd say open BroadcastChannel should keep worker alive. If I read the code right, that is happening in Gecko currently, there is a "WorkerHolder" in BroadcastChannel.

@bakulf

[annevk]

@bakulf wrote in #1004:

GC behavior is not observable: workers are terminated when there are no APIs keeping them alive for some networking (XHR, WebSocket), cross-thread event listeners (MessagePort, BroadcastChannel, etc) or pending async operations, and, of course, if there is not JS code running.

This could be consider an internal optimization also if not part of the spec.

Some of this is explicitly part of the standard, such as MessagePort. We should probably formalize all this a bit better or just claim they cannot be GC'd and stay alive for the duration of their owner(s).

[bakulf]

@SmauG you are right. BroadcastChannel, in gecko, keeps workers alive as well as MessagePort.

[bakulf]

@annevk, in case that BroadcastChannel behavior is not covered by the spec, we should file an issue.
We should have a similar section for BroadcastChannel: https://html.spec.whatwg.org/multipage/comms.html#ports-and-garbage-collection