Make actors hold a strong reference to their IPDL manager
Categories
(Core :: IPC, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox127 | --- | fixed |
People
(Reporter: nika, Assigned: nika)
References
Details
Attachments
(7 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
This will make accessing Manager() safer after an actor's IPC link has been destroyed, as we can hold a strong reference to the manager until the actor's object is fully destroyed.
This requires making all IPDL actors which manage other actors reference counted, similar to how all toplevel protocols were made reference counted in bug 1824465. This is being handled in bug 1874739.
This bug tracks adding the strong reference, and additional code changes will be required to fix the leaks introduced by strong references to managers, and some cycle-collected actors will need to use manual cc-ing to traverse & clear the Manager() edge when unlinking.
| Assignee | ||
Comment 1•2 years ago
|
||
This makes accessing Manager() on an IPDL protocol safer, and replaces the
previous ActorLifecycleProxy reference, which would only keep the manager alive
until IPDL drops its reference.
Unfortunately this introduces some leaks due to reference cycles, which will be
fixed in follow-up parts.
| Assignee | ||
Comment 2•2 years ago
|
||
The strong reference from CanvasManagerChild to WebGPUChild was never cleared
when the WebGPUChild dies, meaning that it would form a strong cycle through
the Manager() reference.
Under the new system, the WebGPUChild actor is kept alive by the IPC
connection, and will be torn down when the IPC connection dies.
| Assignee | ||
Comment 3•2 years ago
|
||
This reference created a cycle after the strong Manager() reference added in an earlier part.
With the reference removed, the VsyncChild will be kept alive via the IPC link
instead, and will be torn down when the IPDL actor is destroyed.
| Assignee | ||
Comment 4•2 years ago
|
||
Previously there was dead code handling DeallocPvsyncParent which hasn't been
called since PVsync was made refcounted. The new logic handles the reference
within IPC, and delays some initialization to the proper constructor.
| Assignee | ||
Comment 5•2 years ago
|
||
While the BackgroundChildImpl actor is not safe to use from any thread other
than the one it was created on, it holds no important thread-bound members at
destruction time, and does no meaningful work in its destructor.
Actors managed by BackgroundChild are occasionally kept alive longer than the
thread they were bound to, meaning that the new Manager() strong reference
would keep BackgroundChildImpl alive past the death of its thread and IPC link.
This change makes the reference counting threadsafe, so that it's OK to destroy
these final references from another thread.
| Assignee | ||
Comment 6•2 years ago
|
||
There are a few IPDL actors which are cycle-collected, including PBrowser,
PContent, and PWindowGlobal.
This patch adds support for these actors to traverse and unlink the new strong
Manager() reference added by IPDL, allowing cycles containing these actors to
be properly unlinked and avoiding leaks.
Comment 9•2 years ago
|
||
There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:nika, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.
Updated•2 years ago
|
| Assignee | ||
Comment 10•1 year ago
|
||
It appears that the Element member may have been creating a reference
cycle passing through the new strong WindowGlobalParent::Manager()
reference.
This patch also removes an unused member from BrowserParent which
otherwise may have needed to be cycle-collected.
Depends on D198629
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/652cf57c384a
https://hg.mozilla.org/mozilla-central/rev/25d1d7b3b88e
https://hg.mozilla.org/mozilla-central/rev/484eaa0f864e
https://hg.mozilla.org/mozilla-central/rev/d536e57bf993
https://hg.mozilla.org/mozilla-central/rev/e013a84d994e
https://hg.mozilla.org/mozilla-central/rev/7ff4113f8b83
https://hg.mozilla.org/mozilla-central/rev/af03c285e0a2
Updated•1 year ago
|
Description
•