Bug 269302 – REGRESSION (STP - ToT): 2.3x memory use increase on Figma

• Status: NEW
• Component: JavaScriptCore

[Dinesh Kumar Vyas]

Public builds having extreamly high Memory uses issue after 270347@main, where STP is not affected with this issue.

Steps to reproduce

1. Open https://www.figma.com/file/FtlkX6BGslQlarHOjJAVXo/macOS-Monterey-UI-Kit-for-Figma-(Community)?type=design&node-id=3-147&mode=design in both STP and Mini Browser (having public nightly WebKit build)
2. Check Memory uses for "Graphics and Media" process in the Activity Monitor. STP uses ~300MBs where Mini Browser with nightly build uses ~700MB

[Alexey Proskuryakov]

Thank you for the report! To clarify, are you saying that 270347@main is the culprit, or just that this regressed at some unknown point between STP and 270347@main? 

I don't think that 270347@main could affect GPU process memory use.

[Radar WebKit Bug Importer]

<rdar://problem/122982826>

[Dinesh Kumar Vyas]

Update: I think its not related to that commit, yet I noticed extra memory uses on some other urls from that commit. But looks like the issue is persist from long time. 

I tested latest nightly build with simple WKWebView and found huge memory uses different when comparing to STP. Also tested STP's WebKit with simple WKWebView to make sure if theres any configuration difference. But the difference is really huge.

Please check attached screenshot, where I tested same URL with default configuration on a WKWebView and STP with single tab and difference is noticeable.

[Dinesh Kumar Vyas]

Created attachment 469873 [details]
Memory uses difference when tested same URL with default configuration on a WKWebView and STP with single tab

Update: I think its not related to that commit, yet I noticed extra memory uses on some other urls from that commit. But looks like the issue is persist from long time. 

I tested latest nightly build with simple WKWebView and found huge memory uses different when comparing to STP. Also tested STP's WebKit with simple WKWebView to make sure if theres any configuration difference. But the difference is really huge.

Please check attached screenshot, where I tested same URL with default configuration on a WKWebView and STP with single tab and difference is noticeable.

[Ryan Reno]

I'm not able to reproduce the behavior with a build from 274981@main or the other two you mentioned. The GPU process has approximately the same memory use as it does in STP 188 on my mac.

It is important to note that there is one GPUP for a given application so if you have more involved reproduction steps than to navigate directly to the provided URL there could be a bug elsewhere. For example is there a flow where you go from the figma homepage to the provided page via some intermediate steps?

[Ryan Reno]

Also, could you please confirm which version of macOS you're using? I see the bug is set to macOS 14 but I'm wondering if you're on one of the point releases or a public beta.

[Dinesh Kumar Vyas]

I am testing on 14.2.1 public release. The issue is reproducible when "GPU Process: Dom Rendering" is enabled. Like STP uses very less RAM but nighly build downloaded from https://webkit.org/build-archives/#mac-sonoma-x86_64%20arm64 uses 2x-3x RAM. 

I also varified WebKit version number and path of loaded WebKit frameworks while testing it.

Let me know if you need any other details.

[Dinesh Kumar Vyas]

I am on M1 machine, if that's relevant.

[Dinesh Kumar Vyas]

Update:

The issue looks related to `ENABLE_REMOTE_LAYER_TREE_ON_MAC_BY_DEFAULT` and we use drawing area type as `DrawingAreaType::RemoteLayerTree`. When we use STP or Safari, GPU process has additional private entitlements for memory management, so GPU process don't cause higher memory uses and that's why there's no memory leak, as all memory allocation and deallocation is performed on WebProcess. 

But in public builds, there's no private entitlements for memory management support in GPU process, so GPU process handles all allocations, but it's not freeing mamory back when needed, and causing memory leak.

[Simon Fraser (smfr)]

Are you concerned about memory use in nightly builds because they reflect memory use in third party apps using WKWebView, or some other reason?

[Dinesh Kumar Vyas]

(In reply to Simon Fraser (smfr) from comment #10)
> Are you concerned about memory use in nightly builds because they reflect
> memory use in third party apps using WKWebView, or some other reason?

Yes, I am concerned about memory uses in nightly builds, as that's behaving differently then STP and Safari (macOS Sonoma only), where STP and Safari seams handling memory allocations in WebContent process, so memory uses in GPU process is normal, and WebContent process releases memory back when needed. 

But when using nightly builds, GPU process seams handles memory allocations for dom rendering, so this causes higher memory uses in GPU process, and it doesn't release allocated memory back and causes leaks. You can see the difference in screenshot attached here https://bug-269302-attachments.webkit.org/attachment.cgi?id=469873 (not sure if the issue is ARM CPU specific)

I can share more information if needed.

[Vladimir Prelovac]

I can reproduce the memoery leak in Graphics and Media process in nightly WebKit build, on Sonoma 14.4 developer beta, Macbook Air M3.


If WebKit is built with Ventura as target, no such issue happens.

[Simon Fraser (smfr)]

Nightly builds are not intended for production use.

[Ben Nham]

This isn't a memory leak, but rather memory attribution working differently in STP vs. nightly.

Safari and STP's GPUProcess have an entitlement which allow them to attribute graphics memory from itself to the WebContent process that is actually requested that memory. For various build process reasons, the nightly build's GPUProcess doesn't have that entitlement, so it can't do that reattribution.

The effect of this is that on nightlies, memory footprint on GPUProcess will be higher and memory footprint in the associated WebContent process will be lower. But the sum of the footprints should still be the same, so there shouldn't be a leak.