Bug 276167
Summary: | Audit all uses of IsStrongCallback | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ryan Reno <rreno> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | rreno, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | 276191, 276267, 276277, 276322, 276332, 276344 | ||
Bug Blocks: |
Ryan Reno
As of 280611@main callbacks are now Weak by default. The owning JS wrapper/C++ object needs to manage the callback lifetime. In the interim, the prior behavior of callbacks being Strong GC roots is maintained via the IsStrongCallback attribute. We should audit all of these callbacks and properly manage the lifetime of the object via visitAdditionalChildren/WebCore Opaque Roots, and any other lifetime management scheme we have available to us.
Strong callbacks are a bit of a memory leak trap so ideally we can remove all uses of IsStrongCallback in time.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/131026926>
Ryan Reno
I'm learning that it's probably not ideal to remove ALL uses of IsStrongCallback. I've found two legitimate uses so far. One is when the callback is "ephemeral". In other words, if there is no owning object and it is scheduled to run in the next run loop/upon promise resolution (examples are requestAnimationFrame's callback and Notification.requestPermission, respectively).
Additionally, if the owning object is an ActiveDOMObject, we can remove the Ref/RefPtr to the callback in ActiveDOMObject::stop which greatly simplifies lifetime management over using JSC::Weak and visitAdditionalChildren.
Ryan Reno
After discussing with rniwa we settled on a design which allows us to remove IsStrongCallback entirely which landed in 280975@main