Bug 277392 - Unexplained memory growth when opening and closing UI Panels
Summary: Unexplained memory growth when opening and closing UI Panels
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Compositing (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified iOS 17
: P2 Critical
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2024-07-30 19:03 PDT by nawaz s
Modified: 2024-09-16 09:06 PDT (History)
5 users (show)

See Also:


Attachments
Within this zip file you will find an attempt to reproduce the issue within a standalone HTML/JS example (22.27 KB, application/zip)
2024-07-30 19:03 PDT, nawaz s
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nawaz s 2024-07-30 19:03:34 PDT
Created attachment 472022 [details]
Within this zip file you will find an attempt to reproduce the issue within a standalone HTML/JS example

In our application, we are experiencing some unexplained memory growth when opening and closing some UI Panels. Several iterations of just opening and closing a panel can result in the application process size with a baseline of 600-700 MB growing upwards until 1.5 - 1.9 GB before the browser forces a reload of the tab.

This memory growth is reproduceable on iOS devices running iOS 17.4 or greater. We've also tested this on the iOS 18 beta seed released during WWDC 2024 and see the same results.

Within this zip file you will find an attempt to reproduce the issue within a standalone HTML/JS example:

    panel-open-close.html

This example illustrates some unexplained memory growth, though not as extreme as seen in our Web Application.  We suspect that this is due to the fact that there is significantly more DOM content in the application.


The test case attempts to replicate the minimal custom elements hierarchy that is at play when hiding/showing the panels triggering this memory growth. We have verified that the DOM itself is getting Garbage Collected so something else on the native side seems to be accumulating/hanging on to memory.

With this test case running about 100 iterations, we are seeing roughly a 160+ MB or so amount of growth even though the DOM nodes being added/removed are GC'ing.

To run the test case simply load it into a Safari browser, set up any memory instrumentation or apps used for memory analysis, and then hit the "Start Test" button. You should then see a some content flashing on the screen at one second intervals.

By default the test runs for 100 iterations. This can be adjusted by searching through open-close-panel.js for the variable called "testIterations" and adjusting its value.
Comment 1 Ryan Reno 2024-07-31 08:04:54 PDT
<rdar://problem/128253881>
Comment 2 Radar WebKit Bug Importer 2024-07-31 08:07:31 PDT
<rdar://problem/132903372>
Comment 3 Ryan Reno 2024-07-31 08:14:43 PDT
My investigation on the live app has shown that WebKit appears to have retain cycle among PlatformCALayer objects. This test case will be very helpful for debugging this cycle, thank you!
Comment 4 nawaz s 2024-07-31 11:12:28 PDT
Thanks Ryan! We have multiple issues/crashes blocked due to this one. It would be highly appreciated if this issue gets resolved soon.
Comment 5 Ryan Reno 2024-07-31 11:31:01 PDT
<rdar://problem/128253881>
Comment 6 Ryan Reno 2024-07-31 11:31:08 PDT
(Forgot to add the InRadar keyword before CCing the bot)
Comment 7 Ryan Reno 2024-08-09 05:44:14 PDT
This reduced test case actually looks to be a different issue. The memory growth in the live app is in layer backing IOSurfaces but the test case attached here is showing a growth of WebKit Malloc objects which is memory allocated on behalf of WebKit and JSC.
Comment 8 nawaz s 2024-08-16 18:17:01 PDT
If the test case attached here is showing a growth of WebKit Malloc objects, then  is that something will be fixed part of this ticket? Also, for the live app issue layer backing IOSurfaces - is there any fix coming up?
Comment 9 nawaz s 2024-08-26 09:15:31 PDT
Hello Ryan,


Out of the 2 issues referenced in this WebKit bug, do they represent the Layers issue and the Malloc issue? And is the team looking into both?

<rdar://problem/128253881>
<rdar://problem/132903372>
Comment 10 Ryan Reno 2024-08-27 08:18:46 PDT
Hello.

rdar://problem/128253881 represents the layer backing memory growth issue. I can repurpose rdar://problem/132903372 to be an investigation into the WebKit Malloc growth in the test case you provided, just need to do some bookkeeping.

For the layer backing issue I've been able to eliminate many possible root causes. I do see an issue with SVG Documents being abandoned via SVGImage objects and it is a likely cause of the layer backing memory growth, though I haven't yet proven that.

I hope that answers your question.
Comment 11 Ryan Reno 2024-08-27 08:19:11 PDT
<rdar://problem/132903372>
Comment 12 nawaz s 2024-08-27 17:51:48 PDT
Thanks Ryan! That's helpful. We are eagerly waiting for those fixes.
Comment 13 nawaz s 2024-09-12 18:17:06 PDT
Hello Ryan,

Do we have any update on these two tickets?

<rdar://problem/128253881>
<rdar://problem/132903372>
Comment 14 Ryan Reno 2024-09-16 09:06:57 PDT
Hello,

I only have a negative result to report. By essentially turning off SVG images and therefore "fixing" the abandoned SVG resources the graphics memory growth slowed considerably but still grows unbounded. So far we have a couple of avenues of mitigation but the problem still hasn't been root caused.

I've also been unsuccessful building a reduced test case which reproduces the graphics memory unbounded growth so far.

I did do tree walks of the layer trees and did not find any cycles in WebKit either. Many of the possible causes have been ruled out.

Apologies I don't have anything more positive to share yet.