New issue
Advanced search Search tips

Issue 879989 link

Starred by 1 user

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocking:
issue 843036



Sign in to add a comment

Implement the "closing orphan workers" algorithm for dedicated workers

Project Member Reported by nhiroki@chromium.org, Sep 3

Issue description

To terminate web workers timely, we should implement the "closing orphan workers" algorithm defined in the HTML spec:

"21. Closing orphan workers: Start monitoring the worker such that no sooner than it stops being a protected worker, and no later than it stops being a permissible worker, worker global scope's closing flag is set to true."
https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model
 
# Background

According to the HTML spec, there're 2 ways to terminate web workers explicitly.

  1) Call Worker#terminate() on the parent context (Document or parent WorkerGlobalScope).
  2) Call WorkerGlobalScope#close() on WorkerGlobalScope.

What if WorkerGlobalScope doesn't call close() and the parent context releases the Worker object without calling terminte()? In that case, the worker is considered as "orphan worker" and should be destroyed when active tasks on the worker are finished or the parent context gets destroyed.

Implementation-wise, the Chromium doesn't implement the "orphan worker" algorithm: the worker lives until the parent context gets destroyed. This may cause memory leak until the parent context destruction, but it was intentional for code simplification (See https://bugs.chromium.org/p/chromium/issues/detail?id=843036#c18 for details). However, according to the recent reports (issue 843036), this case often happens and would be more serious that we expected.
Labels: Target-71
Cc: u...@chromium.org
Thanks for working on this!
Cc: wanderview@chromium.org
Note, there might be something related to this currently missing from the spec.  It has the "protected worker" concept to try to prevent js from observing the GC-triggered orphan worker shutdown:

https://html.spec.whatwg.org/multipage/workers.html#protected-worker

It seems like maybe that should include some text about BroadcastChannel, but it currently doesn't.

I filed a spec issue:

https://github.com/whatwg/html/issues/3993
WebLocks should also probably prevent the orphan worker cleanup:


https://github.com/whatwg/html/issues/3996
wanderview@: Thank you for the information! I'll include them in the CL and design doc.
Sorry, one more thing to consider...  Since the spec tries to make it so hard to observe GC its very difficult to write a WPT for this.  It might be nice to try to standardize some kind of test-only interface that WPT could use to test the existance of a named worker, etc.

And thanks for working on this!
I closely read the worker's spec again and noticed that the "closing orphan workers" algorithm doesn't work for the case described in c#2:

> What if WorkerGlobalScope doesn't call close() and the parent context releases the Worker object without calling terminte()? In that case, the worker is considered as "orphan worker" and should be destroyed when active tasks on the worker are finished or the parent context gets destroyed.

This is because in the case the owner Document still active and the worker is considered as 'active needed worker'.

"A worker is said to be an active needed worker if any its owners are either Document objects that are fully active or active needed workers."
https://html.spec.whatwg.org/multipage/workers.html#active-needed-worker

This means the current implementation is aligned with the spec in that case. Hmm...
We might want to change the spec in order to terminate a worker in the case where there're no active tasks on WorkerGlobalScope, and 'Worker' objects in owner's contexts gets garbage collected regardless of the activeness of the owners.

Sign in to add a comment