Bugzilla

Eliminate busy count tracking in favor of just letting WorkerRefs, the existence of IPC actors, and (newly proposed) the presence of events in our main-thread ThrottledEventQueues keep a worker alive.  This enables a simplification of the WorkerRunnable implementation. This is a spin-off follow-up from bug 1800659 which going to originally address this (but which quite reasonably was de-scoped).

One particular benefit is there is no need for runnables sent to the main thread to have a reference to the WorkerPrivate (to update the busy count), however it's likely that we would want to approximate the original design behavior by having the GC traversal logic in [WorkerPrivate::Traverse](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/WorkerPrivate.cpp#1550) that [Worker::Traverse](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/Worker.cpp#193) calls into:
- Check if there are any runnables in our [mMainThreadDebuggeeEventTarget](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/WorkerPrivate.h#1358) main thread-targeted ThrottledEventQueue.  This is a new proposal with the filing of this bug, but an easy thing for us to check that could potentially allow us to continue to GC in more cases.
- Check if there are StrongWorkerRefs.  (IPCWorkerRefs would continue to not prevent GC, as would also be the case for WeakWorkerRefs.)

Eliminate busy count tracking in favor of just letting WorkerRefs, the existence of IPC actors, and (newly proposed) the presence of events in our main-thread ThrottledEventQueues/worker debugee queues keep a worker alive.  This enables a simplification of the WorkerRunnable implementation. This is a spin-off follow-up from bug 1800659 which going to originally address this (but which quite reasonably was de-scoped).

One particular benefit is there is no need for runnables sent to the main thread to have a reference to the WorkerPrivate (to update the busy count), however it's likely that we would want to approximate the original design behavior by having the GC traversal logic in [WorkerPrivate::Traverse](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/WorkerPrivate.cpp#1550) that [Worker::Traverse](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/Worker.cpp#193) calls into:
- Check if there are any runnables in our [mMainThreadDebuggeeEventTarget](https://searchfox.org/mozilla-central/rev/346a76bee7dc0e60f8f2ae9690785e818bd05cec/dom/workers/WorkerPrivate.h#1358) main thread-targeted ThrottledEventQueue.  This is a new proposal with the filing of this bug, but an easy thing for us to check that could potentially allow us to continue to GC in more cases.
- We also would like to be aware of runnables resulting from Worker.postMessage; most practically having any runnables in the queue would be sufficient but would err on the side of GCing less.
- Check if there are StrongWorkerRefs.  (IPCWorkerRefs would continue to not prevent GC, as would also be the case for WeakWorkerRefs.)