Bug 22308 – Improve Worker GC behavior

• Component: WebCore JavaScript
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Here is what Firefox beta does, and what I suggest that we do as well.

Worker object is GC protected if:
- there is JS executing in its thread,
- there are pending messages in any direction, or
- there is an active object in worker thread, such as a timer, async XHR etc.

A particular feature of this approach is that workers that have made a setInterval() call, or just run a tight loop, will not be collected until their owner is destroyed, even if there is no way left for them to communicate in either direction. This can be seen as a problem leading to likely resource leakage, or as a feature.

There will also be a terminate() call to manually shut down a worker, which Firefox doesn't currently provide.

[Alexey Proskuryakov]

Created attachment 25211 [details]
proposed patch

[Darin Adler]

Comment on attachment 25211 [details]
proposed patch

> +        Made hasPendingActivity() virtul, letting Worker add behavior to it.

Misspelled virtual here.

> +    m_workerContext->thread()->messagingProxy()->reportWorkerThreadActivity(false, m_workerContext->hasPendingActivity());

The use of booleans makes this a little hard to read. It's not obvious what that false means. We can use enums to construct named booleans which help make call sites like this easier to read.

r=me

[Alexey Proskuryakov]

Committed revision 38549.

(In reply to comment #2)
> > +    m_workerContext->thread()->messagingProxy()->reportWorkerThreadActivity(false, m_workerContext->hasPendingActivity());
> 
> The use of booleans makes this a little hard to read. It's not obvious what
> that false means. We can use enums to construct named booleans which help make
> call sites like this easier to read.

I've split this into two functions, reportWorkerThreadActivity and confirmWorkerThreadMessage.