Bug 277392 – Unexplained memory growth when opening and closing UI Panels

• Component: Compositing
• Status: NEW

[nawaz s]

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.

[Ryan Reno]

<rdar://problem/128253881>

[Radar WebKit Bug Importer]

<rdar://problem/132903372>

[Ryan Reno]

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!

[nawaz s]

Thanks Ryan! We have multiple issues/crashes blocked due to this one. It would be highly appreciated if this issue gets resolved soon.

[Ryan Reno]

<rdar://problem/128253881>

[Ryan Reno]

(Forgot to add the InRadar keyword before CCing the bot)

[Ryan Reno]

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.

[nawaz s]

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?

[nawaz s]

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>

[Ryan Reno]

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.

[Ryan Reno]

<rdar://problem/132903372>

[nawaz s]

Thanks Ryan! That's helpful. We are eagerly waiting for those fixes.

[nawaz s]

Hello Ryan,

Do we have any update on these two tickets?

<rdar://problem/128253881>
<rdar://problem/132903372>

[Ryan Reno]

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.